🚀 go-pugleaf

W dniu 2019-11-07 o 21:19, Adam M pisze:

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

No więc właśnie... to też dla mnie udręka. Popełnię drobny błąd (jak w 
wątku) i męczę się z nim. Nawet jeśli jest oczywisty, świeci jak 
latarnia morska, to autosugestia zakazuje dostrzegania go. Trzeba po 
omacku dochodzić przyczyn.

> Może coś
> poprawili na 10 - nie wiem tego bo poprostu sobie odpuściłem
> debugowanie na PostgreSQL 

Szczerze - nawet nie mam pojęcia. Stosuję 11 i 12 lecz nie wydaje mi się 
by w tym względzie ktokolwiek zadziałał.

> na triggerach jak zarazę - procedury składowane tak (pomimo ze i tak
> śą skopane na PostgreSQL

Sęk w tym, że lepszy Postgres niż śmieciowe MariaDB lub stary MySQL, 
który zresztą zdechł. Za inne trzeba czasem srogo płacić. Więc z uwagi 
na istniejący rynek, muszę stosować darmowe rozwiązania. A PostgreSQL 
sprawuje się świetnie, działa wydajnie nawet przy przyrostach rzędu pół 
miliona rekordów dziennie (po paru latach). MySQL (InnoDB) dawno by 
odleciał. Stąd wybór i raczej będę przy nim tkwił.

 > - nie mozna mieć transakcji częściowych w
 > środku procedury/funkcji) - logika na triggerach nie - przynajmniej
 > na PostgreSQL.

Można można i to od dawna ;-)

https://www.postgresql.org/docs/current/sql-savepoint.html

Czemu logika na trigerach nie? Bo trudno debugować? To tylko wydłuża 
developement (bo narzędzie debugingowe kiepskie) lecz nie obniża 
wydajności rozwiązania. Stosuję od lat tego typu podejście i jakoś nigdy 
się na nim nie przejechałem. Mało tego, powiem Ci, że pracowałem w 
firmie obsługującej wierzytelności (ogromne ilości wrażliwych danych - 
drobny błąd danych prowadziłby do kolosalnych strat), która od lat tak 
działa i baza sprawuje się u nich świetnie. Szczerze - nie miałbym się 
do czego przyczepić.

-- 
Pozdrawiam,
Marek