Názory k článku Na co si dát pozor při návrhu databáze?

To su same vyborne rady. Nepouzivajte JOINY v relacnej databaze a nepouzivajte funkcie nad stlpcami. Skvele, zmenim koli tomu specifikaciu systemu a klientovi poviem ze by ten vypocet uzavierky bol pomaly tak ju radsej nebudeme robit.
A samozrejme vsetko si drzte v 4NF cokolvek ine je uz denormalizovane. Uzivatelom dajte len jednoduche nahlady (nejoinovat) oni si to nejako pospajaju v hlave alebo ved na co im je ten excel.
Nie je postup skor opacny ze mam problem a MUSIM ho nejako vyriesit nie sa mu vyhnut? A preto je niekedy dobrym riesenim 'predpocitany' (denormalizovany) stlpec. JOIN cez unikatny dostatocne maly kluc (integer ako unikatny surrogate key) je absolutne rychla zalezitost. A to sme sa nedostali este ani k duplikovaniu udajov z dovodu rozdelenia domenovej logiky. Alebo triky akymi sa vyhnut v multithreadingu dead lockom alebo ako minimalizovat write locky a ako prisposobit databazu takemuto druhu spracovania.
Cely vyvoj databazy je riadeny logikou, nemozem uvazovat iba nad strukturami (domenou) ale aj na funkciami a sposobom akym sa tieto udaje spracovavaju (busines logika). Frekvenciou ich citania, modifikacie a pridavania. Tieto faktory ovplyvnuju akou optimalizacnou strategiou sa rozhodnem ist no a v kazdom pripade nezabudajme na predcasnu optimalizaciu, to je uplne to najhorsie co mozete urobit. Takze priklad so zamestnancami je uplne jedno ako urobite lebo ak ich bude okolo 5.000 a tu najvacsie organizacie v nasich koncinach tak to bude v relacnej DB rychle aj ked to urobite so vsetkymi antipaternami spomenutymi v tomto clanku.
Clanok mozno pre zaciatocnika s SQL dobry ale trochu odtrhnuty od praxe. Ak som to prehnal prepacte snazil som sa byt konstruktivny.

Předpokládám, že ten příklad se zaměstnanci byl uvedený opravdu jen jako jednoduchý, snadno pochopitelný příklad. Nečekal bych, že to někdo vezme tak doslova.

Taky už jsem dělal databázi, u které jsem si říkal, že tam bude jen pár tisícovek záznamů, protože přece i ty největší organizace v našich končinách nemají více než 5000 zaměsnanců, ale pak se z toho vyvinula evidence obyvatel na evropské úrovni (neberte mě zase TAK doslovně - nebyla to evidence lidí).

K funkcím "nad stĺpcami":

select * from data where time > '2016-11-17' and time < '2016-11-18';
50 msecs

select * from data where date(time) = '2016-11-17';
Běží dosud, prohledává sekvenčně miliardu záznamů. Musím to za chvíli zabít, za chvíli mi začnou volat, že něco není v pořádku.

Mozno som bol po ranu precitlively :-). Treba ale zdoraznit ze optimalizovat sa oplati skutocne iba nad skutocne VEEEELKYMI udajmi. Radovo GB dat dnesne stroje zjedia ako nic. Pamatam ze udaje v SAPe jedneho podniku mali 3GB po 2 rokoch pouzivania, v dnesnej dobe by to utiahlo PC za par tisic. Ja dam tiez nieco:
accledgertrans - 150990 zaznamov
Testovaci stroj nejaky normalny server s 30timi virtualmi:
> select count(*) from accledgertrans where createddate between '2016-07-01' and '2016-07-30'
Elapsed time (seconds) - Total: 0.045, SQL query: 0.044
> select count(*) from accledgertrans where date(createddate) between '2016-07-01' and '2016-07-30'
Elapsed time (seconds) - Total: 0.137, SQL query: 0.137

No a prave minuly tyzden sme optimalizovali po 3 rokoch intenzivneho pouzivania databazu. Klient si zacat stazovat ze uz sa to prilis spomalilo. Az po 3 rokoch konecne maju dost udajov a mozeme sa pozriet na dotazy ktore naozaj pouzivaju aby sme ich mohli analyzovat. Nemalo zmysel robit to pred 3mi rokmi. Toto zvladlo zopar indexov, ale robili sme uz aj komplet prerobenie logiky koli optimalizacii. Ano aj to sa robi ale az potom ako mam skutocne udaje a skutocne dotazy. Klientovi sa aj tak neda verit, v case analyzy ani sam netusi kolko tych udajov bude.

Souhlasím s tím, že je celkem zbytečné nějak výrazně optimalizovat databázi dříve, než se v ní objeví dostatečné množství dat. Databáze se někdy chovají na první pohled dost chaoticky a čas strávený dotazem může na objemu dat záviset velmi nelineárně.

Předpokládám ale, že tento článek měl být varováním před něčím jiným, než před předčasnou optimalizací. Velkou část těch situací v článku uvedených jsem si prožil a dnes už tak nějak podvědomě tuším, kudy cesta nevede. Mé dnešní databázové návrhy jsou často poznamenané snahou vyhnout se situacím v článku.

Dneska už na podobně věci myslím už při návrhu aplikace. Spoustu věcí dnes dělám v databázi Sqlite pro PC, Raspberry a podobné stroje - tam to může být kritické i při pár stovkách tisíc záznamů.

Množství a šíře problémů, které se řeší pomocí databází, je mnohem větší, než si my dva dovedeme představit. Myslím si proto, že je dobře, když se s námi někdo podělí o svoje zkušenosti, byť se nám mohou jevit jako banality.

Obecně bych souhlasil, ale je to podle mě trochu složitější. Předesílám, že jsme tedy spíš ze světa Oraclu, ale myšlenkové pochody jsou snad platformě nezávislé, aspoň v tomto případě :)

IMHO na dotazu s mnoha JOINy není nic špatného; např. v normalizované OLTP databázi, kde to vede ideálně na NESTED LOOPy po indexech. Tím spíš, že může být hodně nacachováno a provádí se pak spíš logické IO. A díky statistikám indexů obvykle chyba v odahu není příliš zásadní.
Samozřejmě, že v tom světě skladů má smysl se joinům ideálně vyhýbat, ale někdy to prostě nejde - např. když mi aplikace sype fakta a do reportu musím přidat atributy z dimenzí. Pak ale může mít smysl obětovat normalizaci a join mít ten join předpočítaný a materializovaný; abych ho nemusel počítat pokaždé, když si někdo otevře v BI nástroji první obrazovku. Samozřejmě záleží na zadání - jestli chce BI aktuální přesné hodnoty, nebo třeba v 5min intervalech.

Tím chci jen říct, že opravdu moc záleží na ujasnění si, co vlastně mám dělat. "vyhýbejte se mnoha joinům v dotazu" a "normalizujte, co to jde" - omlouvám se za zkratky, ale snad nejsou úplně mimo - tedy nepovažuji za univerzálně platné rady pro začátečníky, čímž je tedy kategoricky nevyvracím.
Nicméně chápu, že nemusí být rozumné jej hned na začátku vyděsit existencí různých světů s různými pravidly.

Jasně, to jsme pak na stejné lodi ;) Jinak tedy nevím jak v PG, ale v ORA není nutné vždy pálit CPU parsováním/op­timalizováním - plány se cachují a přepoužívají, je-li to možné - pokud tedy někdo neni prase a nedělá "WHERE id = '1'". To jsem bohužel v produkci už viděl a pak samozřejmě cursor_cache obsahuje tisíc podobných ošklivých dotazů, kde rozdíl v SQL jsou právě jen hodnoty ID; prostě to nahoře v JAVE slepili jako řetězec a nazdar, bojuj databáze!
Jasně, ani používání proměnných není samospásné a může vést k jiným problémům; např. v těch DWH je určitě lepší obětovat čas CPU za lepší plán, než šetřit parsování a seknout se (řádově) v kardinalitě, třeba kvůli roztodivné distribuci hodnot. Ale to jsme už trochu jinde... pochopil jsem co chcete říct a souhlasím.

Tenhle článek jsem potřeboval před dvaceti lety. Takhle se můžu jenom pousmát a vzpomenout si, jak jsem byl kdysi nezkušený a blbý = cítil jsem se jako génius (entity-atribute-value - EAV a výsledné dotazy vypadají impozantně a mnohem geniálněji, než poloprázdná tabulka). Otázka je, jestli bych před těmi dvaceti lety článku rozuměl a dokázal se podle toho zařídit. Vždyť EAV vypadá tak sofistikovaně, hodné mého génia - ego je strašná věc.

V létě jsem měl malinký konflikt s jedním mladým zaměstnancem. Zabudoval do jedné drobné, již fungující aplikace vlastní jednoduchou obdobu ORM. S kolegou jsme mu to opatrně rozmluvili a celé jeho ORM zrušili. Ale dodnes mám podezření, že nám stejně neuvěřil. ON by to ukočíroval - ego je strašna věc.

Myslím, že na konstrukce uvedené v článku budete narážet až do konce života.

Tak ORM bylo, nebo asi ještě i je, velmi v módě. Někde má smysl, resp. dobře se s tím pracuje a výkon nijak netrpí, obzvláště v kombinaci s cache jak na straně aplikace, tak na straně databáze, lazy loadingem atd . . . V tom je právě asi to, o čem jsi psal, že nějaká větší optimalizace má smysl až od určité úrovně, resp. složitosti nebo množství (krom obecně platných principů a smysluplných věcí).
A to z Vás ani nikdo nevzpomenul, ale záleží také na tipu databáze a na jazyku, použitém pro systém, ale taky na účelu, protože jinak budeš psát třeba aplikaci, kde záleží na nejakém frontu na každé milisekundě * počet návštěvníků a jinak když je to jedno, hlavně aby programátor co nejrychleji namlátil vypisy složitě souvisejících dat do 15 -30 stránek za týden, nebo to často měnil po malých objememech . . .

S ORM jsem se nikdy nezkamarádil. V mém případě (kolega je na tom stejně) to obvykle vedlo právě k různým děsům v databázové vrstvě, takže část aplikace dělala "někde něco" uvnitř bez rozumné možnosti to ovlivnit a část aplikace byla pracně přepsaná z ORM na optimalizované dotazy. Než mít v jedné aplikaci dva různé přístupy k jedné věci, přijde mi vhodnější to sjednotit.

To byl i důvod, proč se mi nelíbilo ORM vymyšlené kolegou v naší aplikaci. Jednodušší část, se kterou si kolega poradil, byla z jednoduchých selektů přepsaná do jednoduchých mapových struktur (které si musel každý nový příchozí nastudovat a pochopit) a složitá část zůstala ve složitých SQL dotazech.

Jasně. A to je právě to. Klidně můžeš mít na 90% aplikace výpisy relačních dat, na které se to hezky hodí a můžeš sekat třeba templates "jak Baťa cvičky" a pak, u 5~ % udělat složité dotazy, většina ORM to dovoluje a ještě ke všemu ti to vrátí v oněch entitách pokud chceš a pak to zase vysypeš do templaty . . . .
Ale je pravda, že jediné kde si to dokážu opravdu představit tak, aby mi to nikdo nevymluvil je, když vezmeš třeba nějaké Core aplikace - třeba společný admin ke kterému se pak už jenom přidávají custom weby pro klienty a u těch klientů právě sekáš ty templaty a tohle ti hodně pomůže. to jo . . ale jinak to taky rád nemám - už jsem s tím dělal v PHP, Javě, C# a něco podobného a velmi odlehčeného jsem si spíchl pro wordpress, ale já si stejně myslím, že optimalizace má smysl vždycky, protože jednou, až to bude potřeba, už může být úplně pozdě a nebo to být nereálné - např. (cena/výkon) + plánovaný rovoj . . .
Každopádně ORM nebo ne není největší problém tvorby aplikací ani náhodou . . . Už třeba jenom jmenými konvencemi, resp. jejich nedodržováním, se dá udělat harakiri v podstatě z čehokoliv - co jsem se teď naposledy setkal - Máš třeba modul "Description", někdo jeho "main" třídu pojmenuje "Labels", vytvoří z ní instanci "LevýBanner", který si dál předává funkcemi jako LB a do šablony si to pošle jako Blok1 v array "partials" a tohle ti udělá s 10 - 20 komponentama na stánce, tak se můžeš jít klouzat. A pokud tohle udělá s ORM Entitama a sloupcema ["mapping"], tak bych zrovna zařal shánět jiné místo . . . ;-)

podla mna je najdolezitejsie vybrat si databazu a navrh podla problemu - je rozdiel ci ukladas stovky objektov (ciselniky) po 50 records, spatial data, alebo minutove data z burzy za 30 rokov.
kazdy z problemov ma ine poziadavky na zapis a citanie dat .
napriklad zbalenie suvisiacich 1000 datapointov do jedneho BLOBu a ku tomu key bolo asi 140x rychlejsie pre dany problem ako pisat nejake uchylne query cez 7 tabuliek

Pridam jeste jedn oblibeny anti-pattern

select * from table x where x = :filter or :filter is null

Je hezke, ze muzete pouzit jeden SQL dotaz, pro dve ruzne veci. Dokud, ale databaze nevi jakou hodnotu ma bind parametr, tak ani nemuzete vedet, jaky to bude mit exec plan. V realu to konci FTS.

Docela by me zajimalo, jake je doporucovane reseni pro tabulku s heterogennimi daty. Dam priklad - chci ukladat sekvencni vyskyt ruznorodych udalosti, samozrejme jsou tam nejaka data (sloupce) jednotna, typicky treba cas vyskytu nebo typ udalosti, ale zaroven se jednotlive typy udalosti lisi v popisnych atributech. Pokud je tech typu omezene mnozstvi, prijde mi dedicnost jako vhodna aplikace, tady nejde o ORM, ale ta data k tomu podle me prirozene vedou...

Na to není RDB dělaná. Jednou z možností je vystrčit (když to vzhledem k povaze JSONu jde) požadovanou položku z JSONu do dalšího sloupce v záznamu (relaci), který je možno indexovat.

Přejít na MariaDB a použít Dynamic columns by nepomohlo?

Dekuju vsem za odpovedi, asi jsem mel napsat, ze mi jde o relacni DB se zvlastnim prihlednutim k PostgreSQL (protoze Pavel S. je na PG odbornik a shodou okolnosti je to databaze, se kterou pracujeme u nas nejvice). Podobnych prikladu je vic, resime to vselijak, ale nejak se mi nechce pridavat jeste dalsi technologii - snad by mohlo pomoci i vyuziti JSON storage. Zajima me to ale i obecne, co s tim kdo pripadne dela.

Jedná-li se o různé, nepříbuzné typy záznamů, je první chybou dávat je do jediné tabulky, je možno pro každý typ vytvořit jednu.
Jedná-li se o vzájemně příbuzné typy (podtřídy), není pro ně RDB vhodná, ale dá se to ojebat klasickými postupy ORM - buďto pro každý podtyp udělat extra tabuli, nebo to narvat do obecné tabule.
Další možností je použití neschématové DB, tj. dokumentové či jiné, tam je uložení vaším problémem, ne problémem databáze.

Proč název článku mluví obecně o databázích, ale řeší jen relační?
Proč prvním pravidlem návrhu není výběr typu databáze podle typu zpracovávaných dat?
Uvědomuje si autor, že ukládání objektových dat (zřejmé z příkladu) do relační databáze je jeden z nejsložitějších způsobů vzhledem k užití ORM?

ORM je predevsim o tom, ze tvurce nemusi premejslet, protoze se to udela "samo". Ze to bude (pri prekroceni nejakeho mnoztvi dat/zatezi) pomale, pripadne zcela nepouzitelne, neni prevazne v okamziku kdy to dela podstatne. Je dokonce dost pravdepodobne, ze ten problem ktery on vyrobi, bude nasledne muset resit nekdo uplne jiny. Takze proc by se tim mel zabyvat.

BTW: Vubec nejlepsi vec se kterou sem se setkal je mit jednu centralni tabulku IDcek ... a davat do ni i logy. Ono to sice teoreticky je krasne v tom, ze ID je unikatni v ramci cely databaze ... ale taky v tom, ze jen to logovani s naprostym klidem pri prekroceni nejaky kriticky hranice celej system uplne odstavi.

"jednu centralni tabulku IDcek", akoze niekto nepozna sequence alebo autogenerate ID? Za to ORM nemoze.

"ORM je komplikovaná záležitost, a osobně ji beru jako jeden z největších omylů IT", uff. Ale ved ORM je nastroj, dost silny a pre niekoho mozno komplikovany ale OMYL moze byt iba zverit ho nekompetentnemu cloveku. Nastroj ako taky je to vyborny, dnes dokonca v mnohom standardizovany (pre Javu JPA) a robi to co ma, riesi mnohe chyby ktorych by sa programatori dopustali bez neho a vytvara abstrakciu nad rozne DB systemy.
Objektove a NoSQL databazy neriesia mnohe z toho co relacne databazy zvladaju s lahkostou.

Ale to je asi nepochopenie ORM. Prvy ucel je ABSTRAKCIA nad DB. Pokial pouzivam Criteria a HQL je mi jedno s akou DB robim. Mozem si to prepnut na Oracle, PostgreSQL, MS-SQL a vsetko funguje. Za dalsie to OPTIMALIZUJE pristup k udajom pomocou Lazy loading, Eager fetch, Flushing, ... . Ak od biznis logiky zavisi ci potrebujem dalsie udaje pri spracovani nemusim robit zbytocne komplikacie a framework sa postara v pripade potreby o dotiahnutie udajov pripadne optimalizuje updaty v DB, neviditelne a tak aby vsetko fungovalo. No a uplne najviac je to BEST PRACTICE takze postupne ked sa zisti ze existuje optimalnejsi postup na fetch alebo mapovanie udajov z objektu alebo do objektu tak nemusim prerobit celu aplikaciu ale iba dam novsiu verziu frameworku. Je to presne ten isty princip ako Garbage Collector. Super programator to nepotrebuje ale vsetci vo vasom teame su Super programatori? Radsej tam budem mat tento framework ktory vsetci pouzivaju a mozem ako architekt kludnejsie spavat a mozem ist iba po tych vynimkach kedy sa nepouziva a zistit ci je to naozaj potrebne.
No a samozrejme existuju aj specialne 'rucne' robene selecty/updaty pre specialne pripady ale vzdy treba dodrzovat pravidlo 80/20 cize na 80% pripadov by mal stacit framework, 20 urobit rucne. Ak mam pravdu povedat za posledne roky je to u nas asi 95% vsetkeho ciste Criteria a HQL.

„ORM je naprosto zbytečná vrstva...“
Jo? A jak zrekonstruujete objekty bez ORM? Nebo tím snad chcete naznačit, že vaše aplikace pracuje s relacemi?

„Objektove a NoSQL databazy neriesia mnohe z toho co relacne databazy zvladaju s lahkostou.“
Co to je? (Předpokládám, že se bavíme o persistenci pro komplikované objektové systémy, ne o ukládání dat meteorologických stanic.)

1. Předpokládám, že za NoSql myslíte nerelační.
2. Tvrzení „Jsou situace, kdy se NoSQL databáze mohou hodit.“ považuju za (slušně řečeno) hodně odvážné v situaci, kdy obrovské množství systémů v IT zpracovává objektová data (obchodní systémy) a snaží se je s obrovskými a stále se vracejícími problémy narvat do RDB.
3. Z toho mi vyplývá, že jako já považuji, vy nepovažujete za jeden z největších omylů IT snahy o ukládání objektových dat do relací, ale ORM (či některých jeho nakynutých implementací?), které je jen řešením daného rozhodnutí a za nic nemůže.

O čem se tu potom chcete bavit? Postopadesáté o tom, jak narvat objektová data do RDB a jak se je pak pokusit přečíst?

P. S.: Předpokládám, že tu dost lidí bude prskat, ale rozvrstvení informatické populace je přece známé.

Chcete snad říci, že n-tice dat vypadávájící z průmyslového měřicího systému s minimálními či žádnými vazbami na další entity mají stejnou strukturu jako informační systém společnosti s hustě vzájemně propojenými nehomogenními a dokonce se strukturálně měnícími entitami?!!! Už sama existence složitosti ORM vás usvědčuje z toho, že opět kecáte.
Databáze NoSQL jsou pomalejší pouze v prohledávání dat v důsledku jejich volného uložení, tato nevýhoda se však často stírá vhodným modelem obsahujícím podseznamy souvisejících entit, které si ovšem RDB nemůžou dovolit, protože ukládání seznamů neumějí. Není důvod aby pomaleji hledaly dle klíče. Případné horizontální škálování (které v RDB neuděláte) jste zmínil sám.

„Ale už spočítat report, který by vyžadoval konzistentní data a vracel konzistentní výsledky je téměř nemožné - a výrazně pomalejší než nad relační databází.“ Vy si snad děláte prdel! Jak můžete paušálně prohlásit, že v NoSQL bude něco pomalejší, natož že to nejde ani smysluplně spočítat?!

Jestli se cítíte být relačníkem, přejmenujte článek na „Optimalizujeme model a dotazy RDB“ a vyhněte se systémům s databázemi NoSQL, nováčci se vyhnou tradovaným bludům.

Určitě tu bude hodně nesouhlasu (rozložení IT pořád platí), ale snad to pomůže některým otevřenějším začátečníkům.

Tradičně výborný článek od Pavla Stěhuleho. Škoda, že současně s tím root publikuje sérii nekonzistentních a zmatených článků https://blog.root.cz/databaze/postgresql-pl-pgsql-serverove-programovani-02-anonymni-blok/, pro jistotu bez možnost komentářů :-(

Já tam tlačítko pro přidání názoru vidím. Autor bohužel v prvním postu docela "zaperlil" a když mu to nechali čtenáři sežrat, u druhého komentáře zakázal, ale pak si to rozmyslel.

S nazorem

"Relační databáze nijak nepodporují dědičnost (Postgres je výjimka potvrzující pravidlo)."

si dovolim hluboce nesouhlasit.

Kdo nezazil ORA-0600 nad objekty v databazi, netusi, co je to za zlo!

Mohl by mi někdo vysvětlit, jak může RDB řešit dědičnost (nepovinná součást OOP), když neumí ani (z podstaty) uložit objekt?

RTFM

Jo, to připomíná objekty. Mimochodem pro ukládání to používá ORM , neboli objekty to rozstrkává do tabulek.

Taky jsem si na tom spalil prsty. Jako myslenka je to dobry. Bohuzel to pouziva malo zakazniku, tudiz to neni poradne otestovany a Oracle to bohuzel nikdy nedotahnul do pouzitelneho stavu.

Pokud by to slo pouzivat, tak by to melo tu vyhodu, ze by to dokazalo vracet vice-dimenzionalni data a tim by odpadlo spoustu round-tripu mezi aplikaci a databazi.

Pekny clanok prinasajuci imho informacie z rannej praxe vacsiny developrov (teda koderov, nie DB specialistov). Kedze i ja som koder, mam otazku k DB ludom.

Ma zmysel pouzivat postgresql pri CQRS (Command Query Responsibility Segregation) pristupe?

CQRS=> Vsetky zapisujuce operacie tlacia data do "zurnalovej"/event tabulky. Stlpce su ID, idAgregatu (napriklad faktury) a event (udalost, napriklad json stlpec). Teda operacie nad fakturami su rychle, lebo je to append only. Ked niekto ide citat nieco, co sa tyka faktur, tak CQRS vravi, ze pre casto pouzivane operacie je dobre mat query model.

Teda napriklad pre operaciu ziskania faktur spolu so sumou, adresou dorucenia a cenou by bola tabulka s idAgregatu (faktury) a jsonom (alebo jednotlivymi stlpcami). Dopyt na read operaciu sa vybavy rychlo. Vpodstate je to len podanie jedneho riadku tabulky ziadatelovi. Toto pekne funguje, len pri castych updatoch velkych dokumentov, sa moze stat, ze sa updatuje json dokument o velkosti niekolko kb. Je to pre postgresql OK, alebo treba v tomto stave uvazovat nad nejakou nosql DB, alebo zmenit pristup k perzistovaniu QM, alebo to riesit inym sposobom? (niektore QM=predpripravene odpovede k agregatom; sa zvyknu drzat v pamati iba a predvypocitavat pri starte app)

PS: Prepojenie eventov a update query modelu je asynchronne a QM je teda "eventualy consistent". Prosim nerieste tento aspekt cqrs pristupu (vpodstate strata transakcnosti na prvy pohlad), ale len otazku. Teda vhodnost/nevhodnost postgresql na ukladanie/upda­tovanie/citanie "dokumentov" (velkost zvacsa okolo kilobajtu, par vynimiek okolo 100kB).

„...NoSQL databáze oproti relačním databázím umí mnohem hůře hromadné operace - přístup k položkám v JSONu je mnohem pomalejší než sekvenční čtení flat záznamů v relační databázi.“
Samozřejmě, ale jen do okamžiku, než budete muset udělat JOIN nebo čtení z další tabulky tam, kde byste v JSONu sáhnul do podseznamu, což je u netriviálních objektů běžné.
Mimoto v RDB probíná vyhledávání v celých indexech tabulky všech entit jednoho typu (často statisíce záznamů), protože RDB (jak jsem zmiňoval) neumí ukládat seznamy, kdežto dokumentová či objektová DB může využít vyhledávání jen v příslušných seznamech omezených množin entit, což může činit rozdíl množství řádů.

To, co popisujete je technika, která se jmenuje Event Sourcing. S CQRS nemá nic společného, kromě toho, že se často pro implementaci CQRS používá.

CQRS je obecně velmi jednoduché. V podstatě pouze rozděluje systém na 2 části:

1. Write (Command) část sloužící pro zpracování operací, které mění stav systému.
2. Read (Query) část sloužící pro operace, které nemění stav systému - čtení a dotazování.

Na obě části jsou často kladeny jiné požadavky co se týče výkonnosti a škálování. Rozdělením je možné je optimalizovat nezávisle na sobě.
Např. U spousty aplikací je výrazně méně Write operací než Read operací.

Je nutné zdůraznit, že CQRS není top level architektura, ale je často vhodná pouze na malou část aplikace.

Event Sourcing se velmi často používá pro implementaci Write (Command) části, ale není to pravidlo.

Co se týče použití PostgreSQL nebo jiné relační databáze, tak jediná odpověď je: "It depends..."

Vždy je potřeba si klást otázky.

Na jakou část chcete relační db použít? Write? Read? Obě?
Jaké množství dat budete zpracovávat?
Jaký výkon požadujete?
Jak budete jednotlivé části škálovat?
Jaké typy dotazů budete klást na Read část?

Relační db pro Write část:
Jedno z doporučení implementace Event Sourcingu zní: "Nepište vlastní Event Store"
Existuje spoustu řešení nad relačními (i jinými) databázemi a fungují dobře až do doby než se dostanete přes určitou hranici počtu událostí.
Lepší je použít specializované řešení, přece jen je to specifický způsob ukládání dat a specializovaný systém toho umí využít. Často také má implementovánu spoustu šikovných funkcí.
Tím nechci říct, že by se nedal napsat dobrý Event Store nad relační db. Jen je potřeba být připravený na možné problémy.
Na malém systému se s nimi často nesetkáte.

Relační db pro read část:
Tady myslím na problémy nenarazíte. Záleží spíše na typech dotazů. Někdy může být výhodnější použít NoSQL databáze, paměť nebo i něco úplně jiného.

Jinak příklad faktur je pouze vymyšlený příklad nebo něco reálného? Nenapadá mě důvod, proč by v běžné aplikaci měly být faktury implementovány pomocí Event Sourcingu.

Priklad faktur bol vymysleny. Dany pristup (teda event sourcing po spravnosti) pouzivame na viacere (ale nie na vsetky) veci v jednej casti systemu na spracovanie dat. Funguje vyborne a vcelku aj skaluje (dajme tomu nad jednym agregatom ~100k eventov mesacne). Na event store zvazujeme pouzitie kafka serveru, ale zatial vykonnostne postacuje aj postgresql tabulka.

Co sa tyka read casti, tak tam dost dodrzujeme to, ze data su ulozene vo formate/forme, v akom sa poskytuju dalej. Ziadne dohladavania/joiny. Nacitanie z postgresql je vzdy nacitanie jedneho riadku (json/text bunky vpodstate) a nasledne bud priamo preposlanie klientovi (dalsia interna aplikacia), alebo jemne upravenie/pre­formatovanie/o­sekanie v servise. Tu je samozrejme nutne ten json sparsovat a nasledne opat poskladat, ale povaha problemu dovoluje taketo zdrzanie. Ide skor o prietok a ten je mozne pekne skalovat pri dostatocnom pocte procesorov.

Zaujimalo by ma, ci je nejaka prakticka skusenost porovnavajuca napriklad updatovanie casu posledneho pristupu ku kontu poouzivatela (pouzivatel ako agregat) v QM perzistovanom v DB, kde by bol zvoleny json pristup verzus pristup relacnej databazy (napriklad 25 stlpcov, kde jeden je cas posledneho pristupu). Teda rozdiel vykonu pri updatovani jsonb hodnoty s 25 atributmi, verzus updatovanie jednej bunky v tabulke s 25 stlpcami. Je to horsie ako o jeden rad napriklad?

Dakujem za dodatocne informacie.

Na event store zvazujeme pouzitie kafka serveru, ale zatial vykonnostne postacuje aj postgresql tabulka.

Kafku sice moc neznám, ale nepřijde mi jako vhodné řešení pro Event Store
(ale vím, že ji někteří používají a v dokumentaci byla o Event Sourcingu zmínka)

Problémy, které vidím:

1. Pro uložení každého Aggregate (když se budeme bavit v terminologii DDD) potřebujete vlastní Event Stream. Kafka tento koncept nemá a Event Stream by musel být řešen pomocí Topic. V aplikaci můžete mít miliony Aggregate, zvládne to Kafka?
2. Kafka není zamýšlena na dlouhodobé ukládání zpráv, definuje se po jak dlouhé době jsou odmazány. Sice lze nastavit, aby se nemazaly, ale nebylo to takto zamýšleno.

Zkuste se podívat na Event Store

Pro toto existují zvláštní databáze, ale zkušenost s tím nemám. Každopádně hledání dle klíče je základním požadavkem pro dokumentové, key-value i relační DB, se samotným typem DB to tedy příliš nesouvisí, podstatné je, že nejvýhodnější uložení dat je dáno požadovaným použitím.

Jediná použitelná specializovaná databáze pro Event Sourcing (nejen pro něj) je Event Store (o dalších alespoň nevím). Používám ji bez problémů.
Na Lambda meetupu jsem měl na toto téma prezentaci (je tam i odkaz na video)
https://www.meetup.com/Lambda-Meetup-Group/events/220671173/

NEventStore databáze není, je to jen implementace Event Sourcingu nad běžně dostupnými databázemi.

Skvělé, konečně příspěvek k rozšíření obzoru.

ta disputace Palo versus zbytek sveta (pan Jirsak) mi prinutila k tomu take neco rici.

Predne tedy musim priznat, ze se mi nazory slovenskeho kolegy libi. Zvlaste, kdyz vyslovil nasledujici:

....Pokud by měl přístup k databázi, tak nepochybně indexy správně navrhne" -> toto odporuje tomu co sam hovorite kedze vase konzultacie odhaluju tieto problemy aj v pripade cisteho SQL. Preco tito SQL specialisti nenavrhli dotaz a index spravne? Sam pisete ze sa s tym stale stretavate.....

Pan Stehule na to odpovedel v tom smyslu, ze se s problemy setkava u zacatecniku a .... u ORM. To vyzniva tak, jako kdyby nebylo ORM, tak je vetsina problemu s provozem praktickych aplikaci pod SQL hned pryc.

Tato odpoved se mi uprimne receno nelibi. My starsi budeme mit totiz uz brzy jubileum, bude to zhruba 20 let, co pan Stehule upozornuje na zacatecnicke chyby pri navrhu SQL. A tenkrat jeste zadne ORM systemy nebyly. Ten zavaznejsi fakt jsou ovsem ty desitky milionu dotazu na internetu k tem nejjednodussim problemum pri psani tech SQL prikazu? Ze by to vse bylo ORM. Vsechno jsou to zacatecnici?

Ja se obavam, ze se za temi problemy skryva neco jineho. Je to ta SQL sama, ktera nedovoluje tu delbu prace, o ktere Palo hovori. On nechce byt DB specialista Ma plne bryle svych starosti s pozadavky zakazniku, s aplikacni logikou. A proto s radosti sahne k nejakemu nastroji, ktery mu z DB udela nejaky blacbox, ktery muze pouzivat.

Naproti tomu reseni, ktere navrhuji Jirsakove (a neni to jen on, takovych je velka vetsina z tech, kteri se v IT pohybuji) je, aby vsichni k tem svym specialnim dovednostem jeste pridali tu DB specializaci.

Co kdybychom si po tech 20 letech snazeni pana Stehuleho priznali, ze tudy cesta nevede.

Zase plácáte: Na RDB není nepochopitelné SQL, ale relační model, který se v životě moc ničemu nepřibližuje. Když se k tomu ve vývoji přidá ještě neexistence trasovacích nástrojů, primitivnost PL/SQL (např. omezené datové struktury, nutnost předávat složitější výsledky přes dočasné tabulky, ...), je programování RDB docela lopotné.

> ... relační model - to je to nejstarší datové modelování ...

Pavle, tady bych si dovolil nesouhlasit. Hierarchický model je o pár let starší. Relační model ho následně drtivě převálcoval a díky tomu byl skoro zapomenutý.
Až v současné době se znovu vrací v podobě některých NoSQL databází. Je celkem vtipné, že se znovu vynalézá kolo a vývojáři se ani neobtěžují podívat, jak se to řešilo dříve.

Účetní knihy? Ada? Kritické systémy? Dynamika? Data nejdou za 10 let číst? ...
Ne, my se nemůžeme shodnout (zvlášť když vám chvílemi ani nerozumím).

Ja som asi dost konzervativny vyvojar a musim povedat, ze ORM nemam rad. Ak to niekto vyzaduje pouzit, tak nemame s tym problem, ale musime upozornit na nevyhody.
Podla mna je ORM iba urcity modny trend, ktory slubuje vela ale realita je ina ...
Je to podobne ako boli v rokoch 1990 rozne 4GL jazyky. Nieco si v tom rychlo napisal a vygenerovalo to zdrojak v 3GL a skompilovalo.
Problemy vzdy nastali pri rieseni chyb a nestandardnych situacii. Tam si musel debugovat ten vygenerovany kod v 3GL, takze v podstate si sa musel okrem 4GL zaoberat aj 3GL. Cele to bolo na hov...

Jedine velmi male vyhody ORM vidim v tom , ze to za mna porobi administrativne veci ako:
try {} catch {}
rs.close();
stmt.close();
conn.close();
zdrojak DAO, ktory vytvorim bude mozno cez ORM o 1/2 kratsi

Ale ake to prinasa nevyhody ?:
* Som zavisly na cudzom a nestandardnom API/frameworku
* Riesenie chyb je komplikovane - t.j. ked mam v JDBC ten retazec s SQL-prikazom, viem ho 1:1 preniest na SQL-konzolu a verifikovat. Pri ORM je to o dost tazsie oddebugovat a vyriesit to.
* Co mam z toho, ze narobim tie DAO cez ORM rychlo a potom budem v nich dlhodobo riesit chyby, preco nedavaju vysledky ako boli pozadovane ?

Je jednoduchsie vysvetlit programatorom, ze maju v JDBC vzdy robit:
rs.close();
conn.close();
ako riesit nasledky pouzitia ORM.

Neviem si predstavit, co by to boli za programatori, keby im JDBC robilo problemy, ze nevedia pochopit trochu SQL.
A uplne sa stotoznujem s vyrokom P. Stehule: "Tím, že je programátor odtržený od databáze, tak nemá ani šanci se databáze naučit - pochopit ji, uchopit."
Chceme, aby programator nic nevedel o databazi ? Ja to tak nechcem! Som toho nazoru, ze ked niekto nieco pouzivam musim tomu aj rozumiet.

To je zase snůška nesmyslů:

> Som zavisly na cudzom a nestandardnom API/frameworku

Takže komunikaci s databází si píšete zvlášť? Nebo používáte "cizí a nestandardní" JDBC? Pokud JDBC, tak čím je cizejší a nestandardnější než třeba Hibernate?

> Riesenie chyb je komplikovane - t.j. ked mam v JDBC ten retazec s SQL-prikazom, viem ho 1:1 preniest na SQL-konzolu a verifikovat. Pri ORM je to o dost tazsie oddebugovat a vyriesit to.

Zkopírovat SQL z debug logu ORM je "kompikované"? I když pro vás možná ano; lecos by to vysvětlovalo.

> Co mam z toho, ze narobim tie DAO cez ORM rychlo a potom budem v nich dlhodobo riesit chyby, preco nedavaju vysledky ako boli pozadovane ?

Pokud píšete DAO s chybami a neumíte je efektivně opravovat, není to problém ORM.

> Tím, že je programátor odtržený od databáze, tak nemá ani šanci se databáze naučit - pochopit ji, uchopit.

A co se programátor naučí a co pochopí o databázi při opakovaném rutinním lopatování dat tam a zpátky? Vůbec nic. ORM framework tyhle nudné a stále stejné části udělá za něj a on se může věnovat těm složitějším věcem. Takže se s ORM frameworkem klidně může naučit víc.

Já dělám projekty, malé i velké, kde se používá ORM framework (Hibernate) a mám i (středně velký), projekt, kde se ORM dělá ručně za použití přes Spring JDBC. A pokaždé když u něj sahám do DAO a musím ty primitivní věci psát ručně si říkám jak jsme byli blbí, že jsme ho na začátku nepostavili nad Hibernate. Na projektech kde Hibernate používáme s tím žádný problém není.

" ORM framework tyhle nudné a stále stejné části udělá za něj"
Prave ze neudela, a vazne chci videt, jak bude nekdo ladit nejaky query, kdyz libovolna zmena v kodu zmeni i ten dotaz a to klidne i drobna zmena pomerne razantne.

Zjevne ty projekty ktere delate jsou pidiprojekty, takze hruba sila to proste nejak utluce.

> Pokud JDBC, tak čím je cizejší a nestandardnější než třeba Hibernate?
Rozdiel je v tom, ze java.sql patri do standardnej kniznice, Hibernate nie je sucastou, preto je cudzi.

" ze nevedia pochopit trochu SQL"
kde je hranica medzi 'trochu SQL' a 'vela SQL'?
Ja nechcem aby .NET/Java programator riesil a optimalizoval stored procedure v Oracle - to nie je jeho job.

"Chceme, aby programator nic nevedel o databazi ? Ja to tak nechcem! Som toho nazoru, ze ked niekto nieco pouzivam musim tomu aj rozumiet."

ja nechcem aby .NET/Java programator riesil specifika databazy XYZ verzie a.b.c
chcem aby dostal data a spravil s nimi co ma

"Bohatě bude stačit, když bude znát základní principy, které jsou pro většinu relačních databází stejné a více-méně v čase jsou konstantní."

Zakladne principy pozna ORM velmi dobre - presne na to je to vymyslene. Aby ORM pokrylo genericke, opakovane Select, Insert, Update.

A na specializovane 'ficury' programatorovi zakladne principy prave stacit nebudu.

A ja s tim souhlasim. I kdyz musim priznat, ze jedine "ORM", ktere jsem poznal, je DAL ve web2py a SubSonic v .Net. Nejsem zadny velky odobrnik na SQL, ale dost brzo jsem se dostal do situaci, kde moznosti tech dvou vyse uvedenych nestacily. Staci trochu komplikovanejsi select s nekolika joiny a je to v pytli. A pokud se to tvarilo, ze to je OK, tak stejne bylo potreba kontrolovat, jaky z toho vlastne leze SQL dotaz. Takze za nejdulezitejsi vec v techto dvou nastrojich povazuji moznost napsat surovy SQL dotaz.
Ze to pak vysledek namapuje na nejake objekty, to je prima, to nepopiram. Ale to uz je jen takova tresnicka na dortu. Za nejdulezitejsi povazuji, aby to melo dostatecne vyjadrovaci schopnosti a aby to generovalo optimalni SQL dotazy. Bez toho to nejde.

Nejprve bych rád poděkoval za pěkný a erudovaný článek. Jen mě celkem podráždila věta "Co mne zaráží, je neaktivita vývojářů – přidat index je práce na deset minut, a zrychlení aplikace může být neuvěřitelné.".

Problém je v tom, že onen vývojář často aplikaci neprovozuje a ostatně by to tak i mělo správně být. Může samozřejmě udělat syntetické testy a navrhnout nějakou základní sadu indexů, určitě by neměly chybět indexy na referenční integritu apod., ale od finálního indexování je tu databázový administrátor. Od vývojáře se ani nedá očekávat stejná úroveň zkušeností s laděním výkonu, jako od administrátora. Optimálně by ale měli spolupracovat.

Musím říct, že teď jste mne docela překvapil. DB adminy měli zatím všichni moji zákazníci, většinou jich měli několik. A co si nevydupu, to zásadně nemám (myšleno performance data), navíc pokud nejde vysloveně o havarijní stav, tak je s každou i triviální změnou či žádostí o data potřeba projít schvalovacím procesem a počkat na nějakou formu servisního okna. Když nemám u zákazníka vybudované dobré vztahy, může jít klidně i o půl roku. V případě prostého indexu by se to asi podařilo ukecat i bez dobrých vztahů, ale pořád se pohybujeme v reakční době v řádu týdnů. Pokud to nepřijde jako žádost o schválení vytvoření nového indexu od aktivního admina, tak je to většinou v háji.

Jenze vyvoj neni ladeni. Neco jinyho je, kdyz firma pouziva nejaky specificky postup, a na ten se ladi vykon databaze, a neco jinyho, kdyz v databazi nejsou ani indexy na klicich.

Pro predstavu, v systemu je prehled dat, kterej otevre kazdej uzivatel tisickrat denne. Prehled se nad dostatecne velkou databazi otevira klidne i minuty vs mene nez sekundu. To nema nic spolecnyho s nejakym ladenim, to je neschopnost vyvojare.

Nemluve o tom, ze s blbe navrzenou databazi ani ty indexy nic nenadelaj. Krasnej priklad je treba to, ze system generuje logy v takovym mnoztvi, ze je nestiha ani odmazavat - za dobu smazani jednoho zaznamu jich vytvori 10.

„...ale od finálního indexování je tu databázový administrátor...“
Týjo, tak asi tomu moc nerozumím, ale měl jsem za to, že návrh databáze je součástí systému a vývojář by měl vědět, co s tou DB bude dělat, a tedy kde se index vyplatí a kde je na hovno. Aby do toho drbal nějaký chlápek jen podle toho, že se mu zdá, že někde něco jede pomalu, mi přijde docela drsné...