Bežné chyby pri návrhu databázy

Či už pracujete s databázou, ktorá obsahuje stovky záznamov alebo milióny záznamov, správny dizajn databázy je vždy dôležitý. Nielen, že uľahčí získavanie informácií, ale aj v budúcnosti zjednoduší rozšírenie databázy. Bohužiaľ, je ľahké spadnúť do niekoľkých pascí, ktoré môžu v budúcnosti ťažko robiť veci.

Na normalizáciu databázy sú napísané celé knihy, ale ak sa jednoducho vyhýbate týmto bežným chybám, budete na správnej ceste k dobrému návrhu databázy.

Chyba databázy # 1: Opakovanie polí v tabuľke

Základným pravidlom pre dobrý dizajn databázy je rozpoznanie opakujúcich sa údajov a ich opakovanie v tabuľke. Opakované polia v tabuľke sú bežné pre tých, ktorí pochádzajú zo sveta tabuliek, ale zatiaľ čo tabuľky majú tendenciu byť ploché podľa návrhu, databázy by mali byť relačné. Je to ako od 2D do 3D.

Našťastie opakujúce sa polia sú zvyčajne ľahko na mieste. Stačí sa pozrieť na túto tabuľku:

Čo sa stane, keď objednávka obsahuje štyri produkty? Budeme musieť pridať ďalšie pole do tabuľky na podporu viac ako troch produktov. A ak sme vytvorili klientskú aplikáciu okolo tabuľky, aby sme nám mohli pomôcť pri vkladaní údajov, možno bude potrebné, aby sme ju upravili v novom poli produktu. A ako nájdeme všetky objednávky s Jellybeans v poradí? Boli by sme nútení dotazovať každé pole produktu v tabuľke s príkazom SQL, ktorý by mohol vyzerať nasledovne: SELECT * FROM Produkty WHERE Product1 = 'Jelly Beans' alebo Product2 = 'Jelly Beans' alebo Product3 = 'Jelly Beans'.

Namiesto toho, aby sme mali jedinú tabuľku, ktorá by všetky informácie zhromažďovala, mali by sme mať tri tabuľky, z ktorých každá má samostatnú informáciu. V tomto príklade by sme chceli tabuľku objednávok s informáciami o samotnej objednávke, tabuľke Produkty so všetkými našimi produktmi a tabletu ProductOrders, ktorá spojila produkty s objednávkou.

Všimnite si, ako má každá tabuľka svoje vlastné jedinečné ID pole. Toto je primárny kľúč. Tabuľky prepájame pomocou hodnoty primárneho kľúča ako cudzieho kľúča v inej tabuľke. Prečítajte si viac o primárnych a zahraničných kľúči.

Databáza Mistake # 2: Vloženie tabuľky do tabuľky

Toto je ďalšia bežná chyba, ale nie vždy vyčnieva toľko ako opakujúce sa polia. Pri návrhu databázy sa chcete uistiť, že všetky údaje v tabuľke súvisia s sebou. Je to ako hra dieťaťa o tom, čo je iné. Ak máte banán, jahodu, broskyňu a televíziu, televízor pravdepodobne niekde inde.

Podobne, ak máte tabuľku predajcov, všetky informácie v tejto tabuľke by sa mali vzťahovať konkrétne na túto osobu predajcu. Akékoľvek ďalšie informácie, ktoré nie sú jedinečné pre túto predajcu, môžu patriť niekde inde vo vašej databáze.

Zatiaľ čo táto tabuľka môže vyzerat, že je to všetko spojené s individuálnym predajcom, má vlastne tabuľku vloženú do tabuľky. Všimnite si, ako sa Office a OfficeNumber opakujú s "Austin Downtown". Čo ak sa zmenia telefónne čísla? Budete potrebovať aktualizovať celú sadu údajov pre jednu zmenu informácií, ktorá nikdy nie je dobrá vec. Tieto polia by sa mali presunúť do vlastnej tabuľky.

Tento typ dizajnu vám tiež umožňuje pridávať ďalšie informácie do tabuľky Office bez toho, aby ste v tabuľke predajcov vytvorili nočné mory neporiadku. Predstavte si, koľko práce by bolo jednoducho sledovať adresu ulice, mesto, štát a PSČ, ak všetky tieto informácie boli v tabuľke predajcov!

Chyba databázy č. 3: Uvádzanie dvoch alebo viacerých informácií do jedného poľa

Vloženie informácií o kancelárii do tabuľky predajcov nebolo jediným problémom s touto databázou. Pole adresy obsahovalo tri informácie: adresu ulice, mesto a štát. Každé pole v databáze by malo obsahovať iba jednu informáciu. Ak máte viacero informácií v jednom poli, môže sa stať, že je ťažšie získať informácie v databáze.

Napríklad, čo by sme chceli spustiť dotaz na všetkých predajcov z Austinu? Musíme vyhľadávať v adresnom poli, ktoré je nielen neefektívne, ale môže vrátiť zlé informácie. Koniec koncov, čo sa stane, keby niekto žil na ulici Austin v Portlande v Oregone?

Tu by mal vyzerať tabuľka:

Tu je niekoľko vecí. Najprv sa zdá, že adresy "Address1" a "Address2" patria do opakovanej chyby.

V tomto prípade však odkazujú na samostatné údaje, ktoré sa priamo týkajú predajnej osoby, a nie na opakujúcu sa skupinu údajov, ktoré by sa mali nachádzať vo svojej vlastnej tabuľke.

Rovnako ako bonusová chyba, ktorú chcete vyhnúť, si všimnite, ako bolo formátovanie telefónneho čísla odstránené z tabuľky. Mali by ste sa vyhýbať uloženiu formátu polí, ak je to možné. V prípade telefónnych čísel existuje niekoľko spôsobov, ako ľudia napíšu telefónne číslo: 215-555-5858 alebo (215) 555-5858. To by znemožnilo vyhľadávanie predajcu na základe svojho telefónneho čísla alebo vyhľadávanie predajcov v rovnakom oblasti.

Chyba databázy č. 4: Nepoužívajte správny primárny kľúč

Vo väčšine prípadov budete chcieť použiť primárne prírastkové číslo alebo iné generované číslo alebo alfanumerický pre primárny kľúč. Mali by ste sa vyhnúť používaniu akýchkoľvek skutočných informácií o primárnom kľúči, aj keď to znie ako by to urobilo dobrý identifikátor.

Každý z nás má napríklad svoje individuálne číslo sociálneho zabezpečenia, takže používanie čísla sociálneho zabezpečenia pre databázu zamestnancov môže znieť ako dobrý nápad. Zatiaľ čo je zriedkavé, je možné zmeniť aj číslo sociálneho zabezpečenia a my nikdy nechceme, aby sa náš primárny kľúč zmenil.

A to je problém s použitím skutočných informácií ako kľúčovej hodnoty. Môže sa zmeniť.

Chyba databázy č. 5: Nepoužívajte pomenovanie

To nemusí znieť ako veľký problém, keď ste prvýkrát začali navrhovať svoju databázu, ale akonáhle sa dostanete do bodu písania dopytov proti databáze na získanie informácií, bude mať konvencia pomenovania pomôcť, keď si zapamätáte názvy polí.

Len si predstavte, aký ťažší by bol proces, ak by boli mená uložené ako FirstName, LastName v jednej tabuľke a first_name, last_name v inej tabuľke.

Dve najobľúbenejšie konvencie pomenúvajú kapitalizáciu prvého písmena každého slova v poli alebo oddeľovanie slov pomocou podčiarknutia. Môžete tiež vidieť, že niektorí vývojári využívajú prvé písmeno každého slova okrem prvého slova: firstName, lastName.

Budete tiež chcieť rozhodnúť o používaní názvov singulárnych tabuliek alebo názvov plurálnych tabuliek. Je to tabuľka objednávok alebo tabuľka objednávok? Je to tabuľka zákazníkov alebo tabuľka Zákazníci? Znova nechcete, aby ste prilepili tabuľku objednávok a tabuľku Zákazníci.

Konvencia pomenovania, ktorú si vyberiete, nie je taká dôležitá ako proces skutočnej voľby a dodržiavania menovacej konvencie.

Chyba databázy č. 6: Nesprávne indexovanie

Indexovanie je jedným z najťažších vecí, ktoré sa má dať správne, najmä pre tých, ktorí sa pri návrhu databázy radia. Všetky primárne a cudzie kľúče by mali byť indexované. To sú to, čo spolu tabuľky, takže bez indexu, uvidíte veľmi zlé výkon z vašej databázy.

Ale to, čo príliš často chýbajú, sú ostatné oblasti. Toto sú polia "WHERE". Ak často zužujete vyhľadávanie pomocou poľa v klauzule WHERE, chcete premýšľať nad uvedením indexu na toto pole. Nechcete však príliš indexovať tabuľku, čo môže tiež zhoršiť výkonnosť.

Ako sa rozhodnúť? To je súčasť umenia dizajnu databázy. Neexistujú žiadne tvrdé obmedzenia, koľko indexov by ste mali dať na stôl. Najprv chcete indexovať ľubovoľné pole, ktoré sa často používa v klauzule WHERE. Prečítajte si viac o správnom indexovaní databázy.