Názory ke článku Normalizace relačních databází – Programujte.com
 x   TIP: Přetáhni ikonu na hlavní panel pro připnutí webu
Reklama

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

 

Názory ke článku Normalizace relačních databází

Jan Kodera   NOVÝ
23. 7. 2008

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á.

Jasper   NOVÝ
23. 7. 2008

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...

hrach   NOVÝ
23. 7. 2008

Č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...

mylan4   NOVÝ
23. 7. 2008

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.

dalaman   NOVÝ
23. 7. 2008

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

mylan4   NOVÝ
23. 7. 2008

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:

bukaj_001   NOVÝ
23. 7. 2008

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)

bukaj_001   NOVÝ
23. 7. 2008

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)

Earl Cash   NOVÝ
23. 7. 2008

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

Ace McIntosh   NOVÝ
24. 7. 2008

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:

CommanderZ   NOVÝ
25. 7. 2008

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

Anonymní uživatel   NOVÝ
8. 10. 2009

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!

palko   NOVÝ
29. 6. 2010

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

PM   NOVÝ
29. 10. 2011

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...

PM1   NOVÝ
30. 1. 2014

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

Přidej svůj názor

×Vložení zdrojáku

×Vložení obrázku

Vložit URL obrázku Vybrat obrázek na disku
Vlož URL adresu obrázku:
Klikni a vyber obrázek z počítače:
 
Podporujeme Gravatara.
Zadej URL adresu Avatara (40 x 40 px) nebo e-mailovou adresu pro použití Gravatara.
Email nikam neukládáme, po získání Gravatara je zahozen.
-
Reaguješ na příspěvek:
Pravidla pro psaní příspěvků, používej diakritiku. ENTER pro nový odstavec, SHIFT + ENTER pro nový řádek.
Sledovat nové názory e-mailem (pouze pro přihlášené)
Sleduj názory ke článku a v případě přidání nového příspěvku o tom budeš vědět mezi prvními.



Hostujeme u Českého hostingu       ISSN 1801-1586       ⇡ Nahoru Webtea.cz logo © 20032016 Programujte.com
Zasadilo a pěstuje Webtea.cz, šéfredaktor Lukáš Churý