🚀 go-pugleaf

On 2019-04-24, ww <ww@o2.pl> wrote:

[...]

>> To jest tak zwana zła praktyka. Potem inny programista siada i "rzeczy dzieją
>> się magicznie". Zresztą jest to jeden z głównych powodów by nie używać triggerów
>> (obok tego że to bazy danych są zazwyczaj najmniej skalowalnym i najwęższym
>> gardłem systemu i nie należy go nadmiernie obciążać).
>
> Znam wiele "dobrych praktyk", które niestety w nieidealnej 
> rzeczywistości nie chcą się sprawdzać. Jeżeli dostajesz tony danych
> to niestety czasem trzeba poświecić przejrzystość na rzecz wydajności.

Problem w tym, że niektórzy uznają pojęcie "wydajność" za bardzo jednotorowe.

>> W świecie w którym możesz mieć "na zawołanie" 1000 funkcji / kontenerów robiących coś
>> równolegle na infrastrukturze cloud, odpalanych w sekundy, ale np. tylko 1-2 serwery baz
>> danych, to jest oczywiste że dużo bardziej skalowalne są te ostatnie i należy je odciążyć
>> maksymalnie, a nie "dokładać" im niepotrzebnej tam roboty.
>
> Niepotrzebnej tam roboty? U mnie triggery i procedury wbudowane robią 
> zwykle rzeczy, które ze względu na optymalność muszą się odbywać jak 
> najbliżej bazy, i tam właśnie są najoptymalniejsze.

Podałem swoje argumenty dlaczego tak uważam i dlaczego uważam triggery
za mniej wydajne. Nie mam ochoty się powtarzać. Bazy danych są najbardziej
obciążonym kawałkiem w typowych aplikacjach i nie należy ich dociążać.

Triggery są też złe pod tym kątem, że operują na przestrzeni globalnej,
i (przy mniej ogarniętych w DBA programistach) jest ciężko nad nimi 
zapanować, nie zapewniają mechanizmów ułatwiających ich kontrolę, 
wersjonowania, nie pozwalają na efektywną pracę w zespole. 
Ogólnie mają bardzo dużo wad i niewiele zalet.

Jakby taka niskopoziomowa wydajność miała tak duże znaczenie,
to nie pisałbyś w PHP, czy node.js tylko w C.

Poza tym teoria że "trigger" jest 10-krotnie wydajniejszy wydaje mi się 
cokolwiek mocno naciągana. Przepraszam wydajniejszy w czym? Zapytania
SQL wytworzone przez trigger zajmują tyle samo czasu co wysłane przez
aplikację, różnica wynika co najwyżej z czasu dostępów do usługi (co 
nie jest chyba specjalnie istotne).

Tak, narzut uruchamiania aplikacji jest czymś co się odbija 
na wydajności, ale tą aplikację i tak uruchamiamy, jak chcemy
uruchomić query.

Narzut obiektowości w aplikacji wprowadza pewną karę wydajności,
ale jest on dołożony z konkretnych powodów, których nie spełnia
wykorzystanie triggera (ani nie spełnia pisanie aplikacji
w asemblerze, czy w czystym C).

A że trigger jakoś istotnie szybciej przeiteruje po tablicy 
w pamięci niż aplikacja, to wybacz nie wierzę. Język interpretowany 
nie ma dostępu do pamięci "gorszego sortu" tylko tej samej,
chyba że serwer DB stoi na innej infrastrukturze.

>>> I doctrine wspiera tworzenie różnych "nieporzenoszalnych"
>>> elementów składni SQL pod dany silnik.
>> 
>> Nie tyle "wspiera" co "umożliwia".
>
> To dokładnie to samo. Jeśli coś da się zrobić za pomocą wbudowanych
> narzędzi to jest to wspierane.

Nie to miałem na myśli. Wspierane = idzie zgodnie z ideą za jaką idzie
doctrine. Jak zaczniesz stosować swoje hacki, to skończysz na tym, że
np. inne biblioteki/pluginy zależne od Doctrine, które może zechcesz 
użyć mogą się wysypać, bo nie zachowałeś zawartego w Doctrine 
kontraktu. No i w razie problemów na linii core <-> Twoja modyfikacja 
jesteś zdany na siebie.

-- 
Wojciech Bańcer
wojciech.bancer@gmail.com