🚀 go-pugleaf

W dniu 2019-11-06 o 21:54, Adam M pisze:

> 
> Wkładanie logiki biznesowej na triggery to bardzo niebezpieczna zabawa - takie rozwiązania stosowało się epoce SQLa łupanego ;-) - prosciej i bezpieczniej przenieść logikę na middleware.


Tak, wiem, że niebezpieczna. Dlatego 15x to testuję zanim udostępnię.

Owszem, obecnie zwykle przenosi się logikę tego typu do ORMów, a nawet 
widziałem raz sortowanie wykonane w PHP (!!!) w imię przenoszenia 
wszystkiego, co możliwe do wykonania na bazie poza nią. Zauważam, że 
zapanowała wielka awersja do używania baz danych. Zdarza się nawet, że 
obiekty danych trzyma się w formie plików na dysku (patrz Pimcore). Ja 
jednak będę trzymał się w/w rozwiązań. Właśnie jestem świadkiem początku 
upadku sporego przedsięwzięcia - przed czym, u zarania projektu, 
przestrzegałem team. Oni ślepo ufają nowoczesnym rozwiązaniom, jakie 
proponujesz. W efekcie, przy ok 25 mln rekordów w bazie, niektóre proste 
operacje potrafią trwać po kilka minut (klient tyle musi czekać na 
response interfejsu) zamiast kilkadziesiąt milisekund. Przenoszenie 
projektu na super wydajne serwery (hosting parę tys. $), stosowanie 
loadbalacera - odsunęło problem w czasie. Osobiście wygodny ORM stosuję 
tylko tam, gdzie nie może zaszkodzić bardzo: chyba tylko obsługa 
formularzy. Zaczynam przenosić rozwiązania nowoczesne, na łupany SQL i 
już w tej chwili zyskuję min. trzy rzędy wielkości krótsze czasy 
realizowanych operacji.

Jednakże mimo wszystko nie zgodzę się z Tobą, że stosowanie procedur 
składowych w bazie to przestarzałe podejście. Wręcz przeciwnie: widuję w 
korporacjach działy administratorów baz danych, którym wręcz zleca się 
realizowanie procedur składowych, z których korzystają programiści. 
Programiści nie muszą być świadomi nawet tego, że jakąś kolumnę 
przeniesiono z jednej tabeli do innej.

-- 
Pozdrawiam,
Marek