🚀 go-pugleaf

W dniu 24.04.2019 o 15:13, Wojciech Bancer pisze:
> On 2019-04-24, ww <ww@o2.pl> wrote:
> 
>>
>> 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 i procedury wbudowane nie służą tylko i wyłącznie do celów 
optymalizacyjnych.

> 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.

Nie widzę przeszkód w wersjonowaniu kodu procedury składowanej..
Co do pracy w zespole, to przecież osoba pisząca aplikację łączącą się z 
bazą (korzystająca z danych składowanych w bazie) niekoniecznie musi 
wiedzieć, co dana procedura/trigger robi "w środku". Interesują go 
wyniki jakie otrzymuje z bazy.

> 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 wtedy aby przeiterować trzeba z bazy wypchnąć do klienta wszystkie 
rekordy, które mają być przeiterowane, łącznie z rekordami zależnymi, 
żeby otrzymać wynik.
Tutaj to kwestia kompromisu, czy do stu klientów wypchnąć po 
kablach/radiu po np. 5GB żeby sobie przeiterowali lokalnie, czy 
przeiterować 100 razy w bazie i w sieć puścić tylko wynik.
A nawet przeiterować w bazie raz, zapisać wynik w tabeli tymczasowej i 
pchać sto razy wynik po jednej iteracji.

Również chodzi o zapewnienie integralności, spójności danych wewnątrz 
samej bazy, a nie tylko o szybkie iteracje.

Jeżeli z bazą łączą się różne aplikacje (np. Księgowość, Magazyn, 
Sprzedaż itp.), to łatwiej (i bezpieczniej) jest ogarnąć zależności np. 
między dokumentami w bazie, niż w poszczególnych aplikacjach. Im więcej 
różnych aplikacji/modułów tym większa szansa, że w którejś z nich będzie 
błąd i spowoduje rozsypanie zależności.
Dodatkowo, jeżeli potrzebna jest jakaś zmiana, to zmianę wykonujesz w 
jednym miejscu, w bazie, a nie we wszystkich aplikacjach klienckich.
Jeżeli integralność danych pilnowana jest w serwerze danych, to błąd w 
aplikacji np. Magazyn nie spowoduje, że wszystkie inne nagle zaczną 
pokazywać błędne dane.
Tego typu aplikacji nie pisze "wszystko w jednym" (bo po co 
magazynierowi cały kombajn z księgowością?). A nawet udostępnia się 
możliwość pisania dodatków przez firmy trzecie (oczywiście dając jakąś 
warstwę pośrednią, api).
To tak w skrócie i na szybko, że jednak triggery i procedury składowane 
czasem się przydają.

Pozdrawiam
Piotr