🚀 go-pugleaf

W dniu 2019-04-23 o 17:13, Wojciech Bancer pisze:
> On 2019-04-23, ww <ww@o2.pl> wrote:
> 
> [...]
> 
>>> Myślę, że żaden ORM nie obsłuży triggerów.
>>
>> A w jaki sposób ORM miałby te triggery obsłużyć?
> 
> No obsługuje alternatywę, poprzez swoje zdarzenia.
> 
> Nie wiem w jaki sposób miałby to umożliwiać natywnie (czego chyba wymaga Marek S),
> biorąc pod uwagę niesamowity wręcz burdel i brak spójności w triggerach, pomiędzy
> różnymi typami baz.
> 
>> Bo ja ich używam do wielu rzeczy o których ORM kompletnie nie musi
>> wiedzieć.
> 
> 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.

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

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

> Ale koncept za jego rozwojem jednak jest taki, żeby nie dodawać rzeczy
> niekompatybilnych będących specyficznymi wyłącznie dla jednego
> z obsługiwanych dialektów, chyba że nie ma innego wyjścia (jak mamy
> np. w obsłudze primary keys i generation strategy.

Koncepty konceptami a życie życiem.