Názor k článku Svět se strašlivě změnil, ale databáze jsou pořád stejné od KarelE - Ne, struktura databáze nemůže vycházet z požadavků konkrétní...

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.