Jak optymalnie pobierac rekordy z bazy danych

0

Siema, korzystając z Entity Framework zastanawia mnie jak najoptymalniej pobierać rekordy z bazy danych. Zastanawiam się nad dwoma podejściami:

  1. Pobrać wszystkie rekordy z danej tabeli a następnie po stronie servera wyciągać tylko te które mnie interesują
    czy,
  2. Pobierać już interesujące mnie wiersze z tabeli obciążając przy tym bazę danych

Liczę na waszą opinie i pomoc. Może jest jeszcze inny lepszy sposób.Pozdrawiam

4

Filtrowanie danych najwydajniej przeprowadzi baza danych. Chociażby dlatego, że aby filtrować po stronie aplikacji, to najpierw dane musisz do niej przesłać, a transfer często trwa dużo dłużej niż samo operowanie na danych. Poza tym systemy baz danych są zoptymalizowane pod kątem operowania na danych.

P.S. Nie ma czegoś takiego "najoptymalniej". Optymalne to znaczy najlepsze w danych warunkach, lepiej się już nie da.

0

Dokładnie, na studiach co prawda nie ma zbyt wiele pożytecznych informacji, ale uczą nas własnie, że silnik bazodanowy szczególnie teraz gdy do SQL doszły funkcje analityczne powoduje, że o wiele więcej rzeczy możemy i powinniśmy robić w bazie danych a dopiero potem je pobierać do programu.

0

Filtrowanie, agregowanie, łączenie danych praktycznie zawsze po stronie danych.
Jeśli masz sto rekordów, to może przetwarzanie ich po stronie aplikacji zadziała w miarę wydajnie, ale będzie błędem projektowym. Jeśli masz tysiące i więcej wierszy, to aplikacja umrze i pociągnie za sobą bazę danych, zatykając łącze. Dobrze zaprojektowana baza danych (głównie chodzi o strukturę tabel i odpowiednie indeksy) poradzi sobie wydajnie i z milionami wierszy.

0
Leonard napisał(a):
  1. Pobrać wszystkie rekordy z danej tabeli a następnie po stronie servera wyciągać tylko te które mnie interesują
    czy

Najlepiej dokonać takiej optymalizacji bezpośrednio w bazie danych, np. poprzez założenie indeksów na wybranych strukturach (dzięki temu poprawi się szybkość wyszukiwania wybranych rekordów).

0

Chciałbym tylko dodać że nie zawsze filtrowanie po stronie kodu jest błędem projektowym.

Przypadek:
Mamy cienkiego klienta w przeglądarce lub jako apka desktopowa/mobilna. Z serwera pobieramy wstępnie odfiltrowywaną listę rekordów np. po użytkowniku do którego należą. W tym przypadku zakładamy że rekordów będzie średnio 20, a max 100 w skrajnych przypadkach. Wtedy wyświetlamy wszystkie rekordy. Ale zakładając że mamy szereg filtrów dodatkowych po jakichś stanach/datach czy nawet po kolumnach zawierających jakiś tekst, to lepiej jest filtrować już otrzymany zestaw danych niż strzelać ponownie do serwera/bazy.

Efekt ten sam, oszczędzamy liczbę zapytań a klient i tak prawdopodobnie ma więcej mocy żeby sobie odfiltrować ponownie.
Dlatego nie ma tutaj złotego środka, a warto przemyśleć zapytania dla każdego przypadku. Tym bardziej że porządne obmyślenie trwa dużo krócej niż późniejsze przeróbki.

1 użytkowników online, w tym zalogowanych: 0, gości: 1