🚀 go-pugleaf

On 2019-04-24, Kviat <Kviat> wrote:

[...]

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

No na pewno nie służą do zapisywania w nich logiki biznesowej.
Zbyt kiepski to język.

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

Aha. I rollback do tego też?
Albo taka magiczna sztuczka jak przeskok o 2 wersje, połączone
ze zmianami na danych.

> 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 potem osoba od DBA odejdzie i jest "aaayyyyeeeeecosiędzieje".
Widziałem takie podejście wiele razy.

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

I mam uwierzyć, że jak ktoś nie potrafi optymalnie sobie pobrać
danych do procesowania w aplikacji, to zrobi to optymalnie w triggerze.
Tak, jasne.

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

I jak masz 100 takich klientów, to ten ostatni sobie poczeka na wyniki
tydzień, bo maszyna nie ogarnie.

> A nawet przeiterować w bazie raz, zapisać wynik w tabeli tymczasowej i 
> pchać sto razy wynik po jednej iteracji.

Ciągle widzę brak ogarniania koncepcji skalowalności "wszerz".
Macie wszyscy nawyki pisania aplikacji z 10 userami dziennie,
czy może aplikacji desktopowych?

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

Nie. W API. Które jest jedno i tylko ono ma dostęp do bazy.

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

Od logiki biznesowej to jest JEDNA aplikacja, względnie zestaw niezależnych
aplikacji (mikroserwisów) realizujących swoje indywidualne (niezależne) funkcjonalności. 

Wystawia się kontrakt, interfejs, dokumentację, walidację i odpowiada za 
realizację. A nie pół dupy zza krzaka, część w triggerach, część w aplikacji 
(tej której się triggerami nie da), a część bóg wie gdzie.

Aplikacje o których mówiłeś, łączą się do konkretnych usług które potrzebują
(jeśli mówimy o architekturze mikroserwisów), albo do jednej aplikacji (jak
o architekturze monolitycznej) i to one pilnują swojego subsetu reguł.
A nie jakiś kryptyczny kod w bazie.

Dzięki temu masz i większe bezpieczeństwo i większą możliwość fragmentacji,
skalowania, wydzielania, zabezpieczania (dawanie wielu aplikacjom dostępu 
do bazy to jakaś masakra, jak chces zprojektować np. aplikacje mobilne w
takim trybie) i większą skalowalność. Wyobrażasz sobie takie API facebooka 
realizowane z dostępem "na bazie"?

Takie grzebanie po bazie to mi się wydaje charakterystyczne dla aplikacji
księgowych na Windowsa, które instalowały na desktopie bazę, nie udostępniały
API, a wszelkie inne programy "wdrażane" wymagały specjalistów od modyfikacji
tejże bazy. Koszmarek.

> Dodatkowo, jeżeli potrzebna jest jakaś zmiana, to zmianę wykonujesz w 
> jednym miejscu, w bazie, a nie we wszystkich aplikacjach klienckich.

No chyba że zmiana jest niekompatybilna i wtedy trzeba wszysktie aplikacje
klienckie aktualizować, bo baza nie umożliwia porządnego wersjonowania.

[...]

> To tak w skrócie i na szybko, że jednak triggery i procedury składowane 
> czasem się przydają.

Błędne założenia (że dostęp do bazy mają jakieś dziwne aplikacje końcowe, 
to i błędne wnioski.

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