Názor k článku Svět se strašlivě změnil, ale databáze jsou pořád stejné od Miroslav Šilhavý - Většina problémů s výkonem jsou naprosté banality -...

Většina problémů s výkonem jsou naprosté banality - typu programátor neví, co je transakce, fsync, connection pool, atd.

Tohle bohužel neví většina programátorů. Stejně jako u Oracle, tak i u PostgreSQL je potřeba poměrně úzká spolupráce admina a programátora. Programátor nemá šanci pochopit (pojmout) problematiku databáze a jejího výkonu. Správce zase vidí jen IOPSY, CPU, zaplnění WAL, případně dlouhé query. Do nich zase zpravidla nevidí programátor. Když už vidí, je těžké programátorovi vysvětlit, že dotaz nemůže trvat 100 ms, protože pod zátěží by celá DB stála.

To všechno dalo kdysi výhodu jak MySQL, tak NoSQL databázím, protože žádný z těchto "problémů" tam není tématem. MySQL se v podstatě nainstaluje a správce neřeší o moc víc, než kolik dá paměti na cache.

Ze zkušenosti vím, jak je těžké nastartovat v programátorech správné návyky a jak jim vysvětlit, proč je výhodou přenést co nejvíce logiky, výkonu na co nejnižší vrstvu. Setkávám se s názory viz @martinpoljak, že nastavit checky, triggery nebo pravidla na SQL je málo čitelné. Dává mi hodně práce ukázat programátorům, že se to vyplatí. Když si konzistenci dat (tím myslím konzistenci vyšší úrovně, interpretaci dat) hlídá databáze, má aplikace a programátor ušetřenou práci. Nezřídka se v aplikaci řeší totéž na různých místech. Je pak výhodnější, když aplikace a její programátor nemusí na všechno myslet, a mohou se spolehnout, že hraniční stavy ohlídá databáze sama. Na programátorovi pak už je jen interpretovat předané chyby.