Nejčastější chyby v návrhu databáze

Ať už pracujete s databází, která obsahuje stovky záznamů nebo miliony záznamů, správný návrh databáze je vždy důležitý. Nejen, že umožní mnohem snazší načítání informací, ale také v budoucnu zjednoduší rozšíření databáze. Bohužel je snadné spadnout do několika pasti, které mohou v budoucnu složitější.

Na normalizaci databáze jsou napsány celé knihy, ale pokud se jednoduše vyvarujete těchto běžných chyb, budete na správné cestě k dobrému návrhu databáze.

Chyba databáze č. 1: Opakování polí v tabulce

Základním pravidlem pro dobrý návrh databáze je rozpoznávání opakujících se dat a umísťování těchto opakujících se sloupců do vlastní tabulky. Opakované pole v tabulce jsou běžné pro ty, kteří pocházejí ze světa tabulek, ale zatímco tabulky mají tendenci být ploché podle návrhu, databáze by měly být relační. Je to jako z 2D do 3D.

Naštěstí se opakující pole snadno zjistí. Stačí se podívat na tuto tabulku:

Co se stane, když objednávka obsahuje čtyři produkty? K podpoře více než tří produktů bychom museli přidat další tabulku. A pokud jsme kolem tabulky sestavili klientskou aplikaci, která nám pomůže při zadávání dat, možná bude třeba ji upravit pomocí nového pole produktu. A jak najdeme všechny objednávky s Jellybeans v pořádku? Byli bychom nuceni dotazovat každé pole produktu v tabulce s příkazem SQL, který by vypadal takto: SELECT * FROM Produkty WHERE Product1 = 'Jelly Beans' NEBO Product2 = 'Jelly Beans' NEBO Product3 = 'Jelly Beans'.

Namísto toho, abychom měli jediný stůl, ve kterém jsou všechny informace shromažďovány, měli bychom mít tři tabulky, z nichž každá má jasnou informaci. V tomto příkladu bychom chtěli tabulku Objednávky s informacemi o samotné objednávce, tabulce produktů se všemi našimi produkty a tabletu ProductOrders, která propojila produkty s objednávkou.

Všimněte si, jak má každá tabulka své vlastní jedinečné ID pole. Toto je primární klíč. Tabulky odkazujeme pomocí hodnoty primárního klíče jako cizího klíče v jiné tabulce. Přečtěte si více o primárních a cizích klíčů.

Chyba databáze č. 2: Vložení tabulky do tabulky

Jedná se o jinou běžnou chybu, ale ne vždy vyniká stejně jako opakující se pole. Při návrhu databáze se chcete ujistit, že všechna data v tabulce se týkají samy. Je to jako hra dítěte o tom, co je jiné. Pokud máte banán, jahodu, broskvovu a televizní přijímač, televize pravděpodobně patří někde jinde.

Podobně, pokud máte tabulku prodejců, všechny informace uvedené v této tabulce by se měly konkrétně týkat této osoby prodeje. Jakékoli další informace, které nejsou pro tuto prodejní osobu jedinečné, mohou patřit jinam ve vaší databázi.

Zatímco tato tabulka může vypadat, že se jedná o všechno s jednotlivým prodejcem, má vlastně tabulku vloženou do tabulky. Všimněte si, jak se Office a OfficeNumber opakují s "Austin Downtown". Co když se změní telefonní číslo? Budete potřebovat aktualizovat celou sadu dat pro jednu změnu informací, což nikdy není dobrá věc. Tato pole by měla být přesunuta na vlastní tabulku.

Tento typ návrhu také umožňuje přidávat do tabulky Office další informace, aniž byste v tabulce prodejců vytvořili noční můru nepořádek. Představte si, kolik práce by bylo jednoduše sledovat adresu ulice, město, stát a poštovní směrovací číslo, pokud všechny tyto informace byly v tabulce prodejců!

Databázová chyba č. 3: Uvedení dvou nebo více informací do jednoho pole

Vložení informací o kanceláři do tabulky prodejců nebylo jediným problémem s touto databází. Adresní pole obsahovalo tři informace: adresu, město a stát. Každé pole v databázi by mělo obsahovat pouze jednu informaci. Pokud máte více informací v jednom poli, může být těžší dotazovat databázi na informace.

Například, co kdybychom chtěli spustit dotaz na všechny prodejce z Austinu? Budeme muset hledat v adresovém poli, které je nejen neefektivní, ale může vrátit špatné informace. Koneckonců, co se stane, kdyby někdo žil na ulici Austin v Portlandu v Oregonu?

Zde by měl vypadat tabulka:

Zde je několik věcí. Nejprve se zdá, že adresy "Address1" a "Address2" spadají pod chybu opakovaných polí.

V tomto případě však odkazují na samostatné údaje, které se vztahují přímo k osobě prodeje, a nikoli k opakující se skupině dat, která by měla jít do vlastní tabulky.

Také, jako bonusovou chybu, kterou chcete vyhnout, si všimněte, jak formátování telefonního čísla bylo odstraněno ze stolu. Měli byste se vyvarovat ukládání formátů polí, pokud je to vůbec možné. V případě telefonních čísel existuje několik způsobů, jak lidé píší telefonní číslo: 215-555-5858 nebo (215) 555-5858. Bylo by to obtížnější vyhledávat prodejní osobu na základě svého telefonního čísla nebo vyhledávat prodejce ve stejném oboru.

Chyba databáze č. 4: Nepoužívat správný primární klíč

Ve většině případů budete chtít pro primární klíč použít automatické přírůstkové číslo nebo jiné generované číslo nebo alfanumerické. Měli byste se vyvarovat použití jakýchkoli skutečných informací o primárním klíči, i když to zní, jako by to znamenalo dobrý identifikátor.

Například každý z nás má své vlastní číslo sociálního zabezpečení, takže používání čísla sociálního zabezpečení pro databázi zaměstnanců může znít jako dobrý nápad. Ale i když je to vzácné, je možné, že i číslo sociálního zabezpečení se změní a my nikdy nechceme, aby se náš primární klíč změnil.

A to je problém s použitím skutečných informací jako klíčové hodnoty. Může se změnit.

Chyba databáze č. 5: Nepoužívá se pojmenování konvence

To nemusí vypadat jako velký problém, když jste poprvé začali navrhovat databázi, ale jakmile se dostanete do bodu psaní dotazů proti databázi k získání informací, bude mít konvence pojmenování pomáhat při memorování názvů polí.

Představte si, jak těžší bude tento proces, pokud by jména byla uložena jako FirstName, LastName v jedné tabulce a first_name, last_name v jiné tabulce.

Dvě nejpopulárnější konvence pojmenování využívají první písmeno každého slova v poli nebo oddělují slova pomocí podtržítka. Můžete také vidět, že někteří vývojáři značí první písmeno každého slova kromě prvního slova: firstName, lastName.

Budete také chtít rozhodnout o použití názvů singulárních tabulek nebo názvů plurálních tabulek. Je to tabulka objednávek nebo tabulka objednávek? Je to tabulka zákazníků nebo tabulka Zákazníci? Opět nechcete být přilepená tabulkou objednávek a tabulkou Zákazníci.

Konvence pojmenování, kterou zvolíte, není tak důležitá jako proces skutečného výběru a dodržování jmenovací konvence.

Chyba databáze č. 6: Nesprávné indexování

Indexování je jednou z nejtvrdějších věcí, která se má dostat správně, zvláště pro ty, kteří jsou noví v návrhu databáze. Všechny primární a cizí klíče by měly být indexovány. Jedná se o to, jaké propojovací tabulky dohromady, takže bez indexu, uvidíte velmi špatné výkony z vaší databáze.

Ale to, co příliš často chybí, jsou ostatní oblasti. Jedná se o pole "WHERE". Pokud často hledáte zúžení pomocí pole v klauzuli WHERE, chcete uvažovat o uvedení indexu na toto pole. Nicméně nechcete, aby tabulka příliš indexovala, což může také zhoršit výkon.

Jak se rozhodnout? Toto je součást výtvarného návrhu databáze. Neexistují žádné tvrdé limity, kolik indexů byste měli dát na tabulku. Především chcete indexovat jakékoliv pole, které se často používá v klauzuli WHERE. Přečtěte si více o správné indexaci databáze.