Vlákno názorů k článku Svět se strašlivě změnil, ale databáze jsou pořád stejné od Jaroslav Tulach - Jak se stále a stále více dat vejde...

Jak se stále a stále více dat vejde do paměti, přestává být pro rychlost zpracování důležité I/O a umocňuje se rychlost vyhodnocení dotazu - hlavně podmínek v něm napsaných. Před dvaceti lety používaly všechny SQL databáze k vyhodnocování interpret. Myslím, že do budoucna bude nezbytné dotazy překládat (nejlépe dynamickým překladačem jako je v GraalVM).

to je skor chyba navrhu schemy ze sa domena namodeluje tak blbo ze sa tam potom joinuje 5 tabuliek dokopy.

spravne by to malo byt naopak. mam aplikaciu a navrhnem si dotazy a schemu tak aby bola ta query na jeden select v konstantnom case.

takze naopak - rozmyslim si co chcem a spravim schemu aby som to nemusel na sql urovni komplikovat.

toto samozrejme moze byt trochu neflexibilne "ako aplikacia rastie" no existuju postupy ako robitm v nosql svete (cassandra) sa hojne vyuziva duplikacia. sql je postavene na tom, aby som nikde neplytval miestom a mal to vsetko dobre denormalizovane.

v nonsql to nebyva casto problem. je mi jedno ze duplikujem. nemam potom ziadne joiny a query su na jeden select v konstantnom case.

Ne, struktura databáze nemůže vycházet z požadavků konkrétní query. Struktura musí vycházet z dat. To je mor, který vede k neudržovatelným schematům. Vždy to skončí buď smrtí aplikace (už to dál nejde udržet), nebo celým přepsáním.

Ten důvod proč je to tak špatně je v normalizaci. Pokud vám někdo řekl, že je to kvůli plýtvání místem, tak vám ten hlavní důvod tajil. Normalizace je matematický aparát jehož cílem je vyhnout se duplicitním údajům. A ty nejsou problém kvůli místu, které zabírají duplikáty, ale kvůli udržitelnosti dat - každá duplicita totiž komplikuje update a delete. Změna jediného údaje pak totiž obnáší celou sadu updatů duplicitních údajů. U insert only databází je to jedno, ale pokud má databáze podporovat i update, tak je duplicita dat obrovský problém. To vám pak změna jednoho údaje končí updatem několika tabulek. Což je ještě ten menší problém. Větší problém je pak to, když se k tomu dostane jiný programátor a neví, kde všude se to přepsat má a kde ne. Protože některé tabulky jsou "živé" a při změně hodnoty se musí přepsat i tady, zatímco jiné tabulky jsou "historie" a ty se naopak přepsat nesmí.

A hrozná legrace to začne být ve chvíli, kdy se vám do toho začnou motat "defaulty". To je kupříkladu když prodejní položka má název, který se dotáhne do řádku prodejní objednávky ve chvíli, kdy ho vytváříte. Ale v tom řádku prodejní objednávky pak jde přepsat. A vy pak musíte zamítnout code review a znovu opakovat: ano, při updatu popisu položky je potřeba si fulltextově dohledat jiné tabulky, kde jsou sloupce "part_no" s FK na item_master a "part_description" a tam data updatovat taky, ale prodejní a nákupní objednávky jsou výjimka! A ne, výrobní zakázka a pracovní příkaz výjimky nejsou, tam se to přepsat má (shop order a work order přepsat, sales order a purchase order nepřepisovat).

To jako vážně ne, tam se musí oprášit 3NF a dát to do latě. A navíc tam poměrně často bývá takový legrační efekt, že denormalizace se provede aby to bylo rychlejší, ale celé se to tím zpomalí. Ona denormalizace pomůže s OLAP. Jenže je to obrovská zátěž pro OLTP. Je fajn, že vám report skladových transakcí funguje rychleji, jenže vy jste díky denormalizaci přidal do některých OLTP transakcí update nad tou největší tabulkou, kterou v aplikaci máte. Takže update skladové položky rázem místo 10 milisekund trvá minutu. A jako bonus občas timeout na record lock.

Denormalizaci jsme vždy zastavili. Nikdy to nevedlo k ničemu dobrému. Opravdu zásadní problémy s dotazy přes X obrovských tabulek jsme řešili pomocí materialized view nebo pomocí tabulek, které pravidelně nebo na dotaz krmíme přes ETL.

zalezi od aplikacie, ked to je priamociara vec a la IoT kde skoro stale len zapisujem a obcas precitam a viem co robim a aky to ma usecase tak to nie je problem ale vyhoda - dostanem za to nieco ine (nechcem ist tym smerom, ze co, nechcem o tom tu pisat).

ked ale mam nejaku skladovu aplikaciu kde "ani boh" nevie ako sa tie data / schema bude casom menit tak normalne sql tam samozrejme ma vacsiu vyhodu.

osobne som zazil nosql projekt netrivialnej velkosti a po tom ako sa nastavila schema tak sa uz menila len minimalne - len sa pridavali fieldy a tabulky nad tym logika spravila vsetko. nehovorim ze to bolo lahke a ze sme vela krat lutovali ze to nema joiny ale je to proste iny svet a treba sa na to pozerat inak.

aby som bol uplne presny tak my sme velmi neduplikovali pretoze to so sebou prinasa tiez nevyhody - napr. Cassandra ma batch statements ktore simuluju lightweight transakcie a je to trosku narocnejsie na koordinatora ale ked sa to neznasilnuje, tak sa to da pouzit.

za tym nazorom "tabulku si navrhnem podla query" si stojim - stoji na tom cela filozofia Cassandry a ma to velmi silne vyhody ked clovek vie co robi. "schema na query" nie je moj vymysel, staci si o tom nieco precitat - vela ludi je toho zastancom.