czemu zapytania trzymane po stronie bazy są wydajniejsze

Odpowiedz Nowy wątek
2016-05-18 00:58
0

Cześć,
Chciałbym was zapytać czemu zapytania składowane w systemie zarządzania bazą danych są wydajniejsze od zapytań zagnieżdżonych w kodzie aplikacji?
Bardzo mnie interesuje ta kwestia.
Z góry dzięki

Pozostało 580 znaków

2016-05-18 08:18
1

Bo w wielu systemach ich wyniki są keszowane.

Pozostało 580 znaków

2016-05-18 15:28
0

A poza tym, to nie zawsze prawda... A raczej - nie ma na tak postawione pytanie odpowiedzi zero-jedynkowej.
@bananananafu Skąd to twierdzenie, jakiś konkretny przykład?
Jeśli porównujesz wydajność select, to oczywiście zwróciłeś uwagę na czas wysyłki danych do klienta i czas obróbki tych danych przez klienta? Jak spartolisz coś w aplikacji, to baz danych szybciej zwróci dane, niż aplikacja jest w stanie je odebrać.

Pozostało 580 znaków

2016-05-18 20:47
0

Gdzieś tak kiedyś przeczytałem i teraz zacząłem potrzebować odpowiedzi na to pytanie ;p
Wyczytałem, że lepiej, zeby zapytania mielił silnik bazy danych, bo jest bardziej wydajny, ale to są tylko i wyłącznie rzeczy które kiedyś przeczytałem, chyba na tym forum

Pozostało 580 znaków

2016-05-18 21:17
0

Zastanów się... Jeśli zapytanie wysyłasz z aplikacji do bazy danych, to baz danych go nie "mieli"?
A może chodzi Ci o operacje sortowania/filtrowania wykonywane w aplikacji vs baza danych?
Tak czy inaczej, dalej podtrzymuje to co napisałem wcześniej; to zależy...

Pozostało 580 znaków

2016-05-18 22:05
0

Gdyby mnie to nie zastanawiało, to by nie było tego pytania. Naukę o bazach danych zacząłem niedawno, dlatego wolałem zapytać o zdanie tych, którzy wiedzą ode mnie więcej. Dzięki za wszystkie odpowiedzi:)

Pozostało 580 znaków

2016-05-19 06:36
1

Padła już tu częściowo odpowiedź na to pytanie:

Marcin.Miga napisał(a):

Bo w wielu systemach ich wyniki są keszowane.

Ale nie tyle są keszowane wyniki co plany zapytań w wydajniejszy sposób niż zapytania Ad Hoc (procedury są kompilowane). Dane keszowane są i dla Ad Hoc i dla procedur w tzw buffer cachu jeśli mówimy o SQL Server.
Po drugie kwestia możliwości optymalizacji zapytań z aplikacji. Tu też często są ograniczone możliwości optymalizacji jakiś frameworków.
Być może utrzymanie, łatwiej jest poprawić procedurę w SQL niż wydawać nową wersję aplikacji, ale to już są zalety w kwestii organizacji pracy. Tak samo dla administratora SQL łatwiej analizować problemy wydajnościowe.
No to powiedzmy takie podstawowe zalety.


Szkolenia, audyty, konsultacje SQL Server
Radkomp, sqlszkolenia
MCTS, MCiTP, MCSA, MCSE, MCT
http://sqlszkolenia.pl

Pozostało 580 znaków

2016-05-19 08:33
0
firefox napisał(a):

Padła już tu częściowo odpowiedź na to pytanie:

Marcin.Miga napisał(a):

Bo w wielu systemach ich wyniki są keszowane.

Ale nie tyle są keszowane wyniki co plany zapytań w wydajniejszy sposób niż zapytania Ad Hoc (procedury są kompilowane). Dane keszowane są i dla Ad Hoc i dla procedur w tzw buffer cachu jeśli mówimy o SQL Server.

Jeśli już mówimy o SQL Server, to dla zapytań sparametryzowanych plan zapytań jest kompilowany i keszowany w dokładnie ten sam sposób co do procedury składowanej. Rożnica jest taka, że dla procedury robi się to raz podczas "kompilacji", a dla zapytań ad-hoc podczas "preparacji".
Dopóki takie spreparowane zapytanie istnieje w danej sesji, doputy plan jest w keszu.
Szczerze? Tam gdzie nie ma absolutnej potrzeby (czyli np. skomplikowane przetwarzanie jakiś danych), nie używam procedur. Każde zapytanie z aplikacji jest parametryzowane, żadnego sklejania stringów i hardcodowania wartości parametrów. Takiego zapytania SQL Server nie jest w stanie optymalizować i trzymać dla nie planu zapytania w keszu. Podobnie jest i w innych bazach danych...

firefox napisał(a):

Po drugie kwestia możliwości optymalizacji zapytań z aplikacji. Tu też często są ograniczone możliwości optymalizacji jakiś frameworków.
Być może utrzymanie, łatwiej jest poprawić procedurę w SQL niż wydawać nową wersję aplikacji, ale to już są zalety w kwestii organizacji pracy. Tak samo dla administratora SQL łatwiej analizować problemy wydajnościowe.
No to powiedzmy takie podstawowe zalety.

To jest już ograniczenie danej technologii, a nie żadna przewaga SP.

Pozostało 580 znaków

2016-05-19 08:50
cw1
0

Niechęć do stosowania zapytań (widoków) i procedur przechowywanych wynika pewnie z braku doświadczenia w pisaniu kodu SQL. Bez rozpisywania się już klika razy sam byłem zmuszony przenieść zapytania realizowane bezpośrednio w kodzie programu do bazy SQL właśnie ze względu na wydajność. Jedyną poważną wadą jest konieczność aktualizacji bazy (wykonywanie jakiś skryptów SQL czy ręcznie czy też automatycznie) przy okazji aktualizacji samej aplikacji.

Pozostało 580 znaków

2016-05-19 09:11
5
cw1 napisał(a):

Niechęć do stosowania zapytań (widoków) i procedur przechowywanych wynika pewnie z braku doświadczenia w pisaniu kodu SQL.

Moim zdaniem jest dokładnie odwrotnie. SP (Stored Procedure - procedura składowana) zapewnia jednolity dostęp do danych niezależnie od aplikacji. I to jest zaleta, zwłaszcza dla kogoś kto tak naprawdę nie wie i nie rozumie co się dzieje w serwerze.
Miałem już do czynienia z systemem, który posiadał ponad 12 tyś procedur. Na wszystko. Utrzymanie tego czegoś to była dopiero "twórcza" praca...
Widziałem też inny, który dla zwykłej prostej operacji wyświetlenia listy dokumentów robił tak:

  1. Odpalanie jednej procedury, która zwracała ID rekordów do listy
  2. Odpalanie procedury ładowania wiersza, dla każdego wiersza z listy z pkt. 1 (sic!)
    Pewnie autor tego cuda tez przeczytał, że procedury są szybsze...

    cw1 napisał(a):

    Bez rozpisywania się już klika razy sam byłem zmuszony przenieść zapytania realizowane bezpośrednio w kodzie programu do bazy SQL właśnie ze względu na wydajność. Jedyną poważną wadą jest konieczność aktualizacji bazy (wykonywanie jakiś skryptów SQL czy ręcznie czy też automatycznie) przy okazji aktualizacji samej aplikacji.

Tu już nie wytrzymam... To bzdura. Nie ma prostej odpowiedzi, że to samo będzie działało szybciej tylko dlatego że jest w SP. Wiele zależy od tego, jak to było napisane.
Jeśli ktoś w aplikacji pobiera dane, a potem dla każdego wiersza wykonuje zapytanie, które coś tam dobiera z bazy, zamiast to przepisać na złączenia to sorry. Będzie to działało jak kupa. I wtedy faktycznie "przepisałem to na SP i teraz działa 100x szybciej" ma sens. Tylko, to nie do końca prawda...

Aktualizacje bazy danych to jest horror przy często zmieniającym się kodzie, gdzie tej logiki w bazie jest za dużo.
Wielokrotnie obserwuje duże systemy napisane wg "cała logika w bazie", że programiści producenta sami nie widzą co dokładnie się dzieje. Wszystko przez poplątany i zakręcony kod w serwerze, gdzie procedur jest za dużo, używane są wszędzie, zagnieżdża się wywołanie jednej SP w innej, a ta pierwsze wywołana jest przez ciąg triggerów...

I żeby była jasność. Nie jestem przeciwnikiem SP. Ale twierdzę, że trzeba podejść do tematu na zimno i pełnym zrozumieniem zasad. A tu mamy sytuację, gdzie "młody" oczekuje odpowiedzi zero-jedynkowej - co jest lepsze. Nie istnieje jednoznaczna odpowiedź na takie pytanie bez żadnego kontekstu!
A jeśli ktoś twierdzi, że SP są rozwiązaniem wszystkich (powiedzmy - większości) problemów z wydajnością itp. - to po prostu nie do końca ma pojęcie o czym mówi.

Podpisuję się pod tym co napisałeś obiema ręcamy. Swoją drogą świetne podejście do tematu, nie kategoryczne za czy przeciw, tylko dobieranie rozwiązań do potrzeb. Tak to działa, nie każde rozwiązanie wszędzie się sprawdzi. - ŁF 2016-05-19 16:54

Pozostało 580 znaków

2016-05-19 09:48
0

"byłem zmuszony przenieść zapytania realizowane bezpośrednio w kodzie programu do bazy SQL"

W wiekszosci w kodzie mozesz zrobic to samo to w bazie danych tylko trzeba znac interfejs (i zeby ten interfejs nie byl skopany). Takze bardziej obstawialbym ze Twoja znajomosc programowania i interfejsu jakiego uzywaliscie jest slaba niz to ze w bazie dziala szybciej niz z kodu

edytowany 1x, ostatnio: fasadin, 2016-05-19 09:49

Pozostało 580 znaków

Odpowiedz
Liczba odpowiedzi na stronę

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

Robot: Bingbot