🚀 go-pugleaf

On Thursday, November 7, 2019 at 2:06:10 PM UTC-5, Marek S wrote:
> 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

Może trochę zaprzeczę własnemu stwierdzeniu alz zgodzę się z kolegą jeżeli takie rozwiązanie jest stosowane na bazie Oracle , Sybase ASE lub nawet Microsoft SQL gdzie debugowanie kodu SQL po strownie serwera jest łatwe i przyjemne - można wtedy traktować server SQL jak middleware. Niestety PostgrSQL ma fatalny debugger - ostatni jaki używałem był na 9.3 i padał jeśli tylko sie na niego człowiek źle popatrzył nie mówiąc o jakim kolwiek sensownym debugowaniu. Może coś poprawili na 10 - nie wiem tego bo poprostu sobie odpuściłem debugowanie na PostgreSQL is jeśli muszę coś pisac to omijam logikę na triggerach jak zarazę - procedury składowane tak (pomimo ze i tak śą skopane na PostgreSQL - nie mozna mieć transakcji częściowych w środku procedury/funkcji) - logika na triggerach nie - przynajmniej na PostgreSQL.

Pozdrawiam
Adam M