🚀 go-pugleaf

On 2019-04-24, Roman Tyczka <noemail@because.no> wrote:

[...]

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

Jak zapiszesz trigger do git?
Jak zapewnisz bezkonfliktową pracę *zespołu* (nie jednej osobie) na takim
zestawie, rozwiążesz konflikty? Triggery to relikt zamierzchłych czasów 
"one-man-army" programistów.

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

Idąc takim tokiem to należy pisać tylko w assemblerze, wszystko
inne jest dziesiątki razy wolniejsze.

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

Nic się nie traci.

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

To jest koncept postrzegania wydajności "w górę". Takie podejście ma tą wadę,
że jest *skończone*, tzn. w końcu napotyka się na gardło pod tytułem "hardware
więcej nie da". Wystarczy liniowy skok i brak zasobów gotowy.

> Coś za coś, nie jest tak, że jedno jest lepsze niż drugie i droga bez
> triggerów jest słuszna.

Pewne rozwiązania z czasem stają się tzw. anti-patternami.
Przykłady to goto, wzorce singletona. Wkładanie logiki biznesowej
do triggerów też jest pewnego rodzaju anty-wzorcem. Jakby czysta
wydajność była tak kluczowa, to pisalibyśmy wszystko w asemblerze
albo gołym C. Procedury, triggery itp. są koszmarkiem do zarzącania
w porównaniu do alternatyw, a oferują dużo biedniejsze możliwości.
Profit w postaci szybkości nie jest tu wystarczającym argumentem.

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

W dobie rozwiązan cloudowych patrzy się raczej jak coś skalować "w bok" a nie 
tylko przez podniesienie mocy maszyny i mikrooptymalizacje. I tak, przez to
kod pojedynczej aplikacji wykonuje się może te 10x wolniej, ale jesteś w stanie
tego wykonać o rzędy wielkości więcej niż przy skalowaniu w górę. I jesteś 
w stanie reagować na zmiany przez skalowanie ifnrastruktury w miarę wzrostu
obciążenia.

Utrzymywanie kodu na jednym serwerze jest zaprzeczeniem tej idei, a (co już podnosiłem)
bazy danych to sa zazwyczaj najmniej skalowalne elementy infrastuktury. I myślenie
architektów idzie w kierunku zapewnienia możliwej równoległości przeliczeń (co
też sprawdza się w ML), a nie w kierunku optymalizacji bajtowych,
czy oferowanych przez języki programowania.

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