Jak program Access komunikuje się ze źródłami danych ODBC? Część 3

Więcej analizy zapytania dotyczącego populacji kluczy

W części 3 naszej serii śledzenia ODBC przyjrzymy się bliżej kluczom zarządzania programem Access dla tabel połączonych ODBC oraz sposobom sortowania i grupowania zapytań SELECT. W poprzednim artykule dowiedzieliśmy się, że zestaw rekordów typu dynaset to w rzeczywistości 2 oddzielne zapytania, przy czym pierwsze zapytanie pobiera tylko klucze z tabeli połączonej ODBC, która jest następnie używana do wypełniania danych. W tym artykule przyjrzymy się nieco więcej o tym, jak program Access zarządza kluczami i jak wywnioskuje, jaki jest klucz do użycia w tabeli połączonej ODBC, a także jakie ma konsekwencje. Zaczniemy od sortowania.

Dodawanie sortowania do zapytania

Widzieliście w poprzednim artykule, że zaczęliśmy od prostego SELECT bez konkretnego zamówienia. Widziałeś też, jak program Access po raz pierwszy pobrał CityID i użyj wyniku pierwszego zapytania, aby następnie wypełnić kolejne zapytania, aby zapewnić użytkownikowi wrażenie szybkości podczas otwierania dużego zestawu rekordów. Jeśli kiedykolwiek doświadczyłeś sytuacji, w której dodawanie sortowania lub grupowania do zapytania nagle spowalniało, wyjaśnisz, dlaczego.

Dodajmy sortowanie do StateProvinceID w zapytaniu programu Access:

SELECT Cities.*
FROM Cities
ORDER BY Cities.StateProvinceID;

SQLExecDirect: 
SELECT "Application"."Cities"."CityID" 
FROM "Application"."Cities" 
ORDER BY "Application"."Cities"."StateProvinceID"  

SQLPrepare: 
SELECT 
  "CityID",
  "CityName",
  "StateProvinceID",
  "Location",
  "LatestRecordedPopulation",
  "LastEditedBy",
  "ValidFrom",
  "ValidTo"  
FROM "Application"."Cities"  
WHERE "CityID" = ?

SQLExecute: (GOTO BOOKMARK)

SQLPrepare: 
SELECT 
  "CityID",
  "CityName",
  "StateProvinceID",
  "Location",
  "LatestRecordedPopulation",
  "LastEditedBy",
  "ValidFrom",
  "ValidTo"  
FROM "Application"."Cities"  
WHERE "CityID" = ? 
   OR "CityID" = ? 
   OR "CityID" = ? 
   OR "CityID" = ? 
   OR "CityID" = ? 
   OR "CityID" = ? 
   OR "CityID" = ? 
   OR "CityID" = ? 
   OR "CityID" = ? 
   OR "CityID" = ?

SQLExecute: (MULTI-ROW FETCH)

SQLExecute: (MULTI-ROW FETCH)

Zastanówmy się, co się stanie, gdy dodamy GROUP BY obliczając miasta na stan:

SELECT 
   Cities.StateProvinceID
  ,Count(Cities.CityID) AS CountOfCityID
FROM Cities
GROUP BY Cities.StateProvinceID;

SQLExecDirect: 
SELECT 
   "StateProvinceID"
  ,COUNT("CityID" )  
FROM "Application"."Cities" 
GROUP BY "StateProvinceID"

W konsekwencji, tylko dlatego, że domyślnym jest zestaw rekordów typu dynaset, nie gwarantuje to, że w rzeczywistości będzie to zestaw rekordów typu dynaset. To tylko prośba , a nie żądanie.

Określanie klucza używanego do wybierania

Być może zauważyłeś, że w poprzednim śledzonym języku SQL zarówno w tym, jak i w poprzednich artykułach, program Access używał CityID jako klucz. Ta kolumna została pobrana w pierwszym zapytaniu, a następnie użyta w kolejnych przygotowanych zapytaniach. Ale skąd program Access wie, których kolumn tabeli połączonej powinien używać? Pierwszym odruchem byłoby stwierdzenie, że sprawdza klucz podstawowy i używa go. Byłoby to jednak błędne. W rzeczywistości silnik bazy danych Access będzie wykorzystywał SQLStatistics ODBC funkcji podczas łączenia lub ponownego łączenia tabeli w celu sprawdzenia, jakie indeksy są dostępne. Ta funkcja zwróci zestaw wyników z jednym wierszem dla każdej kolumny uczestniczącej w indeksie dla wszystkich indeksów. Ten zbiór wyników jest zawsze posortowany i zgodnie z konwencją zawsze sortuje indeksy klastrowe, indeksy haszowane, a następnie inne typy indeksów. W ramach każdego typu indeksu indeksy zostaną posortowane alfabetycznie według ich nazw. Aparat bazy danych programu Access wybierze pierwszy znaleziony unikatowy indeks, nawet jeśli nie jest to rzeczywisty klucz podstawowy. Aby to udowodnić, stworzymy głupią tabelę z kilkoma dziwnymi indeksami:

CREATE TABLE dbo.SillyTable (
	ID int 
		CONSTRAINT PK_SillyTable PRIMARY KEY NONCLUSTERED,
	OtherStuff int
		CONSTRAINT UQ_SillyTable_OtherStuff UNIQUE CLUSTERED,
	SomeValue nvarchar(255)
);

SQLExecDirect: 
SELECT "dbo"."SillyTable"."OtherStuff" 
FROM "dbo"."SillyTable" 

SQLPrepare: SELECT 
   "ID"
  ,"OtherStuff"
  ,"SomeValue"  
FROM "dbo"."SillyTable"  
WHERE "OtherStuff" = ?

Indeks po stronie dostępu dla połączonego widoku SQL lub tabeli bez indeksów

W przypadku łączenia z widokiem SQL lub tabelą SQL, która nie ma zdefiniowanych żadnych indeksów ani klucza podstawowego, aparat bazy danych programu Access nie będzie mógł używać żadnych indeksów. Jeśli używałeś menedżera tabel połączonych do łączenia tabeli lub widoku SQL bez indeksów, mogłeś zobaczyć takie okno dialogowe:

Jeśli wybierzemy ID , zakończ łączenie, otwórz połączoną tabelę w widoku projektu, a następnie okno dialogowe indeksów, powinniśmy zobaczyć to:

Pokazuje, że tabela ma indeks o nazwie __uniqueindex ale nie istnieje w oryginalnym źródle danych. Co się dzieje? Odpowiedź jest taka, że ​​program Access utworzył stronę dostępu indeks do jego użycia, aby pomóc zidentyfikować, który może być używany jako identyfikator rekordu dla takich tabel lub widoków. Jeśli zdarzy się, że programowo ponownie połączysz tabele, a nie użyjesz Menedżera tabel połączonych, okaże się, że konieczne będzie zreplikowanie zachowania, aby takie tabele połączone można było aktualizować. Można to zrobić, wykonując polecenie Access SQL:

CREATE UNIQUE INDEX [__uniqueindex] ON SillyTable (ID);

Warto zauważyć, że Access zezwoli tylko na jeden indeks dla takiej tabeli połączonej i tylko wtedy, gdy nie ma jeszcze indeksów. Niemniej jednak widać, że użycie widoku SQL może być pożądaną opcją w przypadkach, gdy projekt bazy danych nie pozwala na użycie indeksów klastrowych i nie chcesz bawić się nazwą indeksu, aby skłonić aparat bazy danych Access do korzystania z tego indeksu, nie ten indeks. Możesz wyraźnie kontrolować indeks i kolumny, które powinien zawierać podczas łączenia widoku SQL.

Wnioski

Z poprzedniego artykułu widzieliśmy, że zestaw rekordów typu dynaset zwykle wysyła 2 zapytania. Pierwsze zapytanie zwykle dotyczy wypełniania danych. Przyjrzeliśmy się dokładniej, jak program Access obsługuje wypełnianie kluczy, których będzie używał dla zestawu rekordów typu Dynaset. Widzieliśmy, jak program Access faktycznie przekonwertuje sortowanie z oryginalnego zapytania programu Access, a następnie użyje go w zapytaniu z wypełnianiem kluczy. Widzieliśmy, że kolejność zapytań o populację kluczy ma bezpośredni wpływ na to, jak dane w zestawie rekordów będą sortowane i prezentowane użytkownikowi. Dzięki temu użytkownik może wykonywać takie rzeczy, jak przeskakiwanie do wpisu britrary na podstawie pozycji porządkowej na liście.

Następnie zobaczyliśmy, że grupowanie i inne operacje SQL, które uniemożliwiają mapowanie jeden-jeden między zwróconym wierszem a wierszem pierwotnym, powodują, że program Access potraktuje zapytanie programu Access tak, jakby było zestawem rekordów typu migawka, pomimo żądania zestawu rekordów typu zestaw dynamiczny.

Następnie przyjrzeliśmy się, w jaki sposób program Access określa klucz do zarządzania aktualizacjami za pomocą tabeli połączonej ODBC. W przeciwieństwie do tego, czego można by się spodziewać, niekoniecznie wybierze klucz podstawowy tabeli, ale raczej pierwszy unikalny indeks, jaki znajdzie, w zależności od typu indeksu i nazwy indeksu. Omówiliśmy strategie zapewniające, że program Access wybierze właściwy unikalny indeks. Przyjrzeliśmy się widokowi SQL, który zwykle nie ma żadnych indeksów, i omówiliśmy metodę informowania programu Access o tym, jak kluczować widok SQL lub tabelę, która nie ma żadnego klucza podstawowego, co pozwala nam na większą kontrolę nad tym, jak program Access będzie obsługiwał aktualizacje dla te tabele połączone ODBC.

W następnym artykule przyjrzymy się, w jaki sposób program Access faktycznie wykonuje aktualizacje danych, gdy użytkownicy wprowadzają zmiany za pomocą zapytania programu Access lub źródła rekordów.

Nasi eksperci ds. dostępu są gotowi do pomocy. Zadzwoń do nas pod numer 773-809-5456 lub napisz do nas na adres [email protected].