🚀 go-pugleaf

On Tue, 23 Apr 2019 22:31:12 +0200, Wojciech Bancer wrote:

>> Po drugie, jak wspomniałem przy okazji codziennych importów po pół 
>> miliona rekordów. Jeden mój ruch i prawie dwukrotnie szybciej proces 
>> zaczął działać. A pewnie gdyby przeprojektować system, to i z 10-krotnie 
>> dałoby się przyspieszyć.
> 
> Myślę że Twoja praca kosztowała więcej niż koszt działania serwera
> przez te kilka godzin. No i jak sobie z firmy pójdziesz, to ktoś
> będzie musiał rozgryzać "dlaczego magicznie coś się dzieje" na bazie,
> skoro w kodzie aplikacji nic nie ma.

Dziwne to wnioskowanie. Dlaczego treść triggerów i sp nie traktujesz jako
kod źródłowy systemu? Tak samo struktura bazy to kod źródłowy aplikacji.
Niektóre systemy są pisane w kilku językach programowania, każdy ten
fragment jest częścią systemu.
Druga sprawa z tym unikaniem triggerów w celu oszczędzania wydajności to
imho właśnie zabijanie wydajności i spójności. Trigger przy danych wykona
się dzięsiątki razy szybciej niż kod gdzieś w oddali, zwłaszcza
interpretowany. Ja rozumiem, że np. jak sobie rozrzucisz ten kod po 10
serwerach aplikacyjnych to one go wykonają w sumie szybciej, ale wtedy
tracisz fundamentalną cechę bazy czyli ACID, bo wszystko to wykona się w
osobnych transakcjach bez gwarancji niepodzielności i spójności. A jeszcze
co do transakcji to kluczowe jest by transakcje aktualizujące dane były jak
najkrótsze, wykorzystanie triggera skraca ten czas, użycie kodu na zewnątrz
wydłuża, co ciągnie za sobą problemy z blokowaniem zasobów bazy i dalsze
spadki wydajności.
Coś za coś, nie jest tak, że jedno jest lepsze niż drugie i droga bez
triggerów jest słuszna. Być może jest tak jak Marek sugeruje, że na rynku
brakuje fachowców od baz danych i się to załatwia ORMami, nie rozumiejąc co
się w zamian traci.

-- 
pozdrawiam
Roman Tyczka