Názory ke článku Normalizace relačních databází – Programujte.com

Nevím odkud jste čerpal, ale je to hezky popsané a snad to lidem vysvětlí základy normálových forem. Určitě dřív nebo později si zvyknou.

Ovšem možná brzy narazí na to, že trend je denormalizovat data. Jak jste správně uvedl normalizace dat vám výkon nezvýší, právě naopak. Dostanete se do víru spojování tabulek, složitých dotazů. A ve chvíli kdy budete potřebovat výkon od aplikace začnete přemýšlet jak na to. Jeden z osvědčených způsobů jsou materializované pohledy. Tedy ten složitý select vyústí v tabulku. A nad tou tabulkou se bude pracovat. Někde vzádu se bude krčit vaše databáze v normálové formě.

Samozřejmě se vedou spory kudy do toho. Celé to začalo, když se zjistilo že databáze jsou bezvadná věc, ale jaksi je potřeba se dostat co nejblíže fyzické rychlosti disku, páč je to on kdo zdržuje. Google na to používá obrovskou hash mapu a databáze používá pouze občas. Jiní na to jdou denormalizaci dat, což zase způsobuje že musí udržovat dvě schémata a vlastně zdvojují data. Když přičtete nutnost zálohovat, jejich spotřeba disků není malá.

Možná by se ještě hodilo dodat, že správný návrh DB by měl být v min. 3NF, do kterého se dá dostat vždy. BCNF již nelze vždy provést...
Taky bys v dalším díle mohl popsat algoritmy pro převod do 3NF. Teď si to dělal asi intuicí, ale lepší by bylo popsat algoritmy syntézy a dekompozice, uzávěry atd...

Člověk by ani neřekl, že existují takové velké teorie. Nikdy jsem podobný materiál nečetl, ale on se člověk osobně většinou dostatene sám do takového toho středu, kdy ještě není práce si ty table pospojovat, ale zase nemám žádné velké duplicity dat...

No neviem, ale podľa mňa by bolo lepšie používať ako primárny kľúč číselné ID.
Napr. tabuľka fotiek a tabuľka albumov: ak sa zmení názov albumu v tabuľke albumov, budem ho musieť prepísať aj v tabuľke fotiek (zdvojenie dát). Ak by mal každý album okrem názvu a popisu aj ID, nebol by s tým problém -> z fotky by som odkazoval na daný album práve cez dané ID.

Suhlasim s mylan4. POuzit ciselne ID je lepsie, ale chapem ze ucelom clanku bol nieco ine.

Dobre sa to citalo, fajn clanok ;) Dufam ze budes pokracovat v podobnych

Reagoval na komentář od uživatele dalaman :
Nechcem sa hádať, ale pokiaľ som dobre pochopil článok, tak účelom bolo práve toto.
Na jednej strane rozdelil tabuľku, aby sa zabránilo opakovaniu dát (pole "Popis albumu"), na druhej strane sa názov albumu aj tak opakuje. :smile11:
Ale článok aj tak veľmi dobrý. Dobré čítanie. :smile2:

Reagoval na komentář od uživatele Petr Kašpar :
Možná by se ještě hodilo dodat, že správný návrh DB by měl být v min. 3NF, do kterého se dá dostat vždy. BCNF již nelze vždy provést...
Hlavně ono se dneska spíš než normalizuje denormalizuje (o čemž psal Jan Kodera). 3NF je takový dobrý kompromis.

Taky bys v dalším díle mohl popsat algoritmy pro převod do 3NF. Teď si to dělal asi intuicí, ale lepší by bylo popsat algoritmy syntézy a dekompozice, uzávěry atd...
Bohužel, ale žádný přístí díl s takovým popisem algoritmů nechystám. Jestli ale chceš, klidně se toho můžeš ujmout ;o)

Reagoval na komentář od uživatele mylan4 :
No neviem, ale podľa mňa by bolo lepšie používať ako primárny kľúč číselné ID.
Bylo. A čekal jsem, že někdo se přesně s tímhle ozve. Chtěl jsem rovnou do článku umístit upozornění, že příklady jsou jen modelové, že v praxi by se právě vytvořil jako primární klíč sloupec s nějakým id, s nímž se dá zacházet mnohem lépe, ale nakonec jsem si řekl, že ne. No, jak vidím, měl jsem to tam radši umístit :o)

tvoje clanky je radost cist....jen tak dal.....

Tak tomuhle já říkám kvalitní počtení. Článek mě čtivou a nenucenou formou velmi obohatil o cenné informace a určitě rozšířil mé obzory v oblasti návrhu databázových řešení. Díky za něj a do budoucna přeji hodně dalších úspěšných článků:smile2:

...se skryvaly naproste zaklady navrhu databazi. Myslim, ze tenhle clanek by si mel povinne cist kazdy nez se na neco zepta v sekci MySQL :)

máte tam špatně vysvětlený příklad, tvrdíte, že je ve třetí normální formě, ale jeho dva neklíčové atributy jsou závislé: PSČ a město!

Reagoval na komentář od uživatele Anonymní uživatel :
Ano je to tak....

Ad denormalizace vs. normalizace: jasně, že pro reportování, vyhledávání a podobné "rychlostní soutěže" je potřeba data denormalizovat...

ALE většinou TRANSAKČNÍ SYSTÉMY vyžadují normalizaci. Jakékoliv porušení tohoto, je přidávání kódu na obsluhu datové integrity (a tím zpomalenému zápisu dat - vyřízení transakce) na úkor získané rychlosti při čtení dat.

A samozřejmě, běžná aplikace není jen čistý TRANSAKČNÍ SYSTÉM...

Jen mi někdo řekněte, co jsou to fotki? Děkuji

#12 Anonymní uživatel
Sice je to po tolika letech úplně jedno, ale stejně si neodpustím připomínku: jak jsou na sobě závislé atributy PSČ a město? Který je závislý na kterém? Vy mi podle města dokážete určit PSČ? Někdy jsou různá PSČ i v rámci jedné ulice jednoho města. Nebo mi u každého PSČ dokážete říct jedno konkrétní město? Nezažil jste nikdy adresu typu Horní Dolní 20, pošta Střední Dolní? PSČ představuje číslo poštovního uzlu. A poštovních uzlů může být a často bývá v jednom městě více. A naopak jsou obce, které svůj poštovní uzel mají ve vedlejší obci... Tak si odpusťte vykřičníky, když melete nesmysly.