Wczytywanie z bazy dużej liczby rekordów

Witam wczytuje tabelę z bazy danych tabela zawiera około 1000 rekordów, używam jej potem do kontrolki AutoCompleteBox aby wyświetlić podpowiedzi. Czy są jakieś sposoby żeby skrócić proces zapytania i pobrania danych za bazy danych za pomocą SQL. Używam Microsoft SQL Express.

A jesteś pewien, że to wina zapytania? 1000 rekordów to jest żałośnie mało, duzo rekordow to są powiedzmy miliony czy dziesiatki milionów (a i to ciezko nazwac big data). Jeśli coś działa wolno to bardziej winiłbym renderowanie tego.
Poza tym jeśli dane się nie zmieniają szybko to można to trzymać w cache w pamięci.

Agregacja danych. Poza tym jak wyzej - 1000 rekordow to powinna byc sekunda ladowania niezaleznie od jakosci zapytania

Ja bym nie szukał raczej winy po stronie bazy, bo 1000 rekordów to jest żadna ilość. SQL operują setkami tysięcy czy milionami rekordów i nie ma z tym żadnego problemu. Raczej bym się zastanowił, czy to ta kontrolka o której piszesz nie zamula podczas dodawania do niej pozycji.
Zakładając, że SQL stoi na innej maszynie niż apka z tą kontrolką, możesz sprawdzić - odpal menedżera zadań i obserwuj obciążenie procka (oraz jak się zachowuje Twoja aplikacja). Jeśli nie będzie znaczącego wzrostu, to znaczy że wąskim gardłem rzeczywiście może być SQL albo np. komunikacja przez sieć. ALE jeśli CPU podczas zapełniania kontrolki wartościami pobranymi z bazy będzie obciążone, to raczej by oznaczało, że sam proces updateowania zawartości kontrolki powoduje lagi.

cerrato napisał(a):

Zakładając, że SQL stoi na innej maszynie niż apka z tą kontrolką, możesz sprawdzić - odpal menedżera zadań i obserwuj obciążenie procka (oraz jak się zachowuje Twoja aplikacja). Jeśli nie będzie znaczącego wzrostu, to znaczy że wąskim gardłem rzeczywiście może być SQL albo np. komunikacja przez sieć. ALE jeśli CPU podczas zapełniania kontrolki wartościami pobranymi z bazy będzie obciążone, to raczej by oznaczało, że sam proces updateowania zawartości kontrolki powoduje lagi.

Ja wiem, że w wielu technologiach brakuje toolingu, ale takie rzeczy to się profiluje dokładniej niż patrząc na menedżer zadań... Szczególnie, że czas dostępu to można po prostu System.Diagnostics.Stopwatch sprawdzić.

@Saalin: oczywiście, ale biorąc pod uwagę problem kolegi - czyli że zapytanie do bazy z 1k rekordów powoduje opóźnienia i za bardzo nie wie, co z tym zrobić - nie wiem, czy podsuwanie tego typu narzędzi go nie przerośnie. I nie piszę tego złośliwie czy w formie dogryzania - po prostu stwierdzam fakt, że tutaj raczej mamy osobę początkująca, więc może nie ogarnąć jakichś bardziej zaawansowanych narzędzi.

To zastanówmy się głośno co jest trudniejsze:

1. Operacje na SQL, robienie interfejsu okienkowego
2. Dodanie timestempa przed operacja, po operacji i odjęcie czasu. Podpowiem, że Stopwatch dokładnie tak działa, nikt nie mówi tu o topornych toolach typu GDB.

Dopóki nie ma dokładnych pomiarów to ja nie wierzę, że to query trwa długo, a patrzenie na menedżer zadań przy tak krotkich operacjach może co najwyżej doprowadzić do złych wniosków.

Spróbuję ze stopwatch zobaczymy co i jak.

Przetestowałem Stopwatch, na moim lapku działa to świetnie, dostałem laptop do wgrana tego programu, niestety bardzo stary i na tym starym laptopie wczytywanie z bazy trwa 2 sekundy a wczytywanie do kontrolki 32 sekundy :P

Możliwe, że podczas uzupełniania kontrolki trzeba wyłączyć jej odświeżanie, być może niektóre eventy. Przynajmniej tak się robiło z gridami/listview w WinFormsach.

Sprawdź przyrostowo dla 5, 10, 25 rekordów jakie są czasy. Wydaje mi się, że problem leży po stronie renderowania tego.

Teraz wczytuje jakieś 30 rekordów i dalej jest taki sam czas oczekiwania. Chodzi o to że przetwarzam wiersze poprzez SqlDataReader następnie w pętli While odczytuje je, i to chodzi tak wolno. Execute reader chodzi szybko tylko jak daje przetwarzanie rekordów w pętli na przyklad:
while(dataReader.Read()){ // przetwarzanie} to schodzi dość długo

Nie, baza danych i serwer są dostępne poprzez VPN.