Dostęp połączony z serwerem SQL

Question

Jeśli użyję Access, aby połączyć się z bazą danych SQL Server, czy prędkość będzie taka sama?

Na przykład mam tabelę [TEST] w bazie danych SQL Server, z indeksem na kolumnie [ID]. Jeśli napiszę zapytanie SQL w środowisku SQL Server:

SELECT .... 
FROM TEST 
WHERE ID = ...; 

Indeks działa (lub pomaga). Gdybym nie odwołuje się do tego [TEST] użyciu programu Access i napisać kwerendę w programie Access:

SELECT .... 
FROM TEST 
WHERE ID = ...; 

prędkość będzie taka sama jak odpytywanie danych w środowisku SQL Server? Czy istnieje jakiś sposób, aby go przetestować, jak plan wykonania, lub SQL Server Profiler w SQL Server?

Dzięki

Answer 1

prędkość będzie taka sama jak odpytywanie danych w środowisku SQL Server?

Ogólnie: tak. Z mojego doświadczenia wynika, że ​​w przypadku większości zapytań czas wykonania na serwerze będzie mniej więcej taki sam w obu przypadkach. Oczywiście istnieje mały koszt sieci, aby wyświetlić dane w programie Access, więc całkowity czas wykonania może być odrobinę wyższy.

Istnieją jednak wyjątki. Miałem kilka złożonych kwerend, zwykle z jednym lub więcej lewych złączeń, które wykonują abyssmicznie, gdy wykonywane w programie Access, ale bez żadnych problemów, gdy wykonywane na SQL Server.

Dla tych przypadków (zauważysz je!), Użyj pytań tranzytowych w programie Access. Są wykonywane bezpośrednio na serwerze w formie pisemnej, bez interpretowania przez sterownik ODBC.

Answer 2

Robię coś podobnego, ale z redbrick, a nie serwerem sql. Oto moje spostrzeżenia:

Korzystanie z kwerendy przekazującej powoduje niewielką różnicę w wydajności. Jednak dane wyjściowe będą tylko do odczytu, co może, ale nie musi być tym, czego potrzebujesz.

Używanie projektanta zapytań dostępu, w pojedynczej tabeli, przy użyciu złożonego klucza podstawowego, może być błyskawiczne lub straszliwie wolne. Jeśli zapytanie nie zwróci żadnych wierszy, natychmiast otrzymasz pusty zestaw wyników. Jeśli jednak zapytanie zwróci dane, jest to inna historia.

W tym przykładzie użyto tabeli o nazwie clinic_fact z kluczem podstawowym o numerze rejestracyjnym i pozycji klatki. Ma około 6,5 miliona rekordów. Jeśli bezpośrednio prześlesz zapytanie do bazy danych, filtrując pojedynczy numer rejestracyjny, otrzymasz natychmiastowe wyniki. W dostępie uzyskanie wyników zajmuje ponad 10 sekund. W tym czasie zobaczę, jaki sql jest generowany. To wygląda tak.

select yourfields 
from "clinic_fact" 
where "registration_number" = 'something' and "clinic_position" = 2 
or "registration_number" = 'something' and "clinic_position" = 1 
or "registration_number" = 'something' and "clinic_position" = 1 
or "registration_number" = 'something' and "clinic_position" = 1 
or "registration_number" = 'something' and "clinic_position" = 1 
or "registration_number" = 'something' and "clinic_position" = 1 
or "registration_number" = 'something' and "clinic_position" = 1 
or "registration_number" = 'something' and "clinic_position" = 1 
or "registration_number" = 'something' and "clinic_position" = 1 
or "registration_number" = 'something' and "clinic_position" = 1; 

Ta kwerenda zwraca 2 wiersze. Pozycje kliniki to 1 i 2.

Takie rzeczy mogą, ale nie muszą wystąpić w przypadku SQL Server. Sugeruję, abyś spróbował i zobaczył.

Answer 3

Jeśli użyję Access, aby połączyć się z bazą danych SQL Server, czy prędkość będzie taka sama?

Zależy od rodzaju zapytania, które wykonujesz. Zauważyłem, że zazwyczaj dla zapytań SELECT czas wykonania kończy się w zasadzie tak samo, ale dla niektórych zapytań UPDATE i DELETE wydaje się, że są naprawdę powolne. To powiedziawszy, myślę, że każdy, kto pracował z Access przez chwilę, zgodzi się, że czasami zachowuje się nieco nieoczekiwanie. Musisz więc spróbować i porównać końcowe wyniki.

Answer 4

Tak długo, jak robisz wszystkie połączenia i klauzule w indeksowanych polach, powinny być względnie podobne po stronie serwera. Problemy pojawiają się, gdy używasz mechanizmu zapytań dostępu do pobierania danych z połączonych tabel i używasz nieindeksowanych pól.

W takich przypadkach program Access lubi wykonywać różne czynności, np. Żądać wszystkiego od i wykonywać filtry po stronie klienta. Skutkuje to mocniejszym uderzeniem serwera, mocniej uderza w sieć i zmusza twoją maszynę do przeszukiwania znacznie większej ilości danych, aby wyświetlić zestaw wyników.

Kwerenda tranzytowa to zdecydowanie najlepszy sposób na uniknięcie tego rodzaju problemów. Kilka ostrzeżeń dotyczących przesyłania kwerend z DAO:

• Nie można przypisać parametrów do kwerend tranzytowych DAO, więc jeśli potrzebujesz elastycznych kryteriów, musisz użyć dynamicznego SQL.
• Ty może temat złożonej rzeczy w DAO pass-through zapytań (np deklaracje zmiennych, uruchamianie wielu zapytań w kolejności, kursorów (jeśli trzeba), itd) ale aby zrobić coś bardziej skomplikowanego niż pojedyncza oświadczenie, będziesz nam potrzebować ZESTAW NOCNOUNT NA, w przeciwnym razie Access dusi się, gdy pierwsza instrukcja zwróci swój status.

(Jeśli pracuję w kodzie, generalnie wolę używać ADO dla zapytań tranzytowych, głównie dlatego, że pozwala mi używać parametrów, i jestem super paranoikiem na temat dynamicznego SQL (szczególnie jeśli jest ciąg znaków wejściowych Minusem jest to, że ADO nie obsługuje środowisk JET, jak również DAO.)