Uobičajene pogreške u dizajnu baze podataka

Bilo da radite s bazom podataka koja sadrži stotine zapisa ili milijune zapisa, pravilno oblikovanje baze podataka je uvijek važno. Ne samo da će to olakšati dohvaćanje informacija, već će i pojednostaviti širenje baze podataka u budućnosti. Nažalost, lako je pasti u nekoliko zamki koje u budućnosti mogu otežati stvari.

Postoje cijele knjige napisane na temu normalizacije baze podataka, ali ako jednostavno izbjegavate ove uobičajene pogreške, bit ćete na dobrom putu do dobrog dizajna baze podataka.

Pogreška baze podataka # 1: Ponavljanje polja u tablici

Osnovno pravilo za dobar dizajn baze podataka je prepoznavanje ponovljenih podataka i stavljanje tih ponavljajućih stupaca u vlastitu tablicu. Ponavljanje polja u tablici uobičajeno je za one koji su dolazili iz svijeta proračunskih tablica, ali dok se proračunske tablice obično planiraju prema dizajnu, baze podataka trebaju biti relacijske. To je kao da ide od 2D do 3D.

Srećom, ponavljajuća polja obično su jednostavna za uočavanje. Pogledajte ovu tablicu:

Što se događa kada narudžba sadrži četiri proizvoda? Trebali bismo dodati još jedno polje na stol kako bismo podržali više od tri proizvoda. Ako smo za stvaranje aplikacije klijenta oko stola pomogli u unosu podataka, možda ćemo je morati mijenjati s novim poljem proizvoda. A kako nalazimo sve naloge s Jellybeansom u redu? Mi ćemo biti prisiljeni upita svaki polje proizvoda u tablici s SQL izjavom koja bi mogla izgledati: SELECT * FROM Proizvodi GDJE Proizvod1 = 'Jelly Beans' ILI Product2 = 'Jelly Beans' ILI Product3 = 'Jelly Beans'.

Umjesto da ima jednu tablicu koja sadrži sve informacije zajedno, trebali bismo imati tri tablice koje svaka drži zaseban podatak. U ovom primjeru željeli smo tablicu Narudžbe s podacima o samoj narudžbi, tablici proizvoda sa svim našim proizvodima i tabletu ProductOrders koji su povezivali proizvode s narudžbom.

Primjetite kako svaka tablica ima svoj vlastiti ID polje. Ovo je primarni ključ. Povezujemo tablice pomoću primarne ključne vrijednosti kao stranog ključa u drugoj tablici. Pročitajte više o primarnim ključevima i stranim ključevima.

Pogreška u bazi podataka # 2: Ugradnja tablice u tablicu

Ovo je još jedna uobičajena pogreška, ali se uvijek ne ističe jednako kao i ponavljajuća polja. Prilikom izrade baze podataka, želite osigurati da se svi podaci u tablici odnose na sebe. To je kao igra djeteta oko uočavanja onoga što je drugačije. Ako imate bananu, jagodu, breskvu i televizor, televizija vjerojatno pripada negdje drugdje.

Uz istu liniju, ako imate stol o prodajnim osobama, sve informacije u toj tablici trebale bi se odnositi posebno na tu prodajnu osobu. Sve dodatne informacije koje nisu jedinstvene za tu prodajnu osobu mogu pripadati negdje drugoj u vašoj bazi podataka.

Iako ova tablica može izgledati kao da je sve povezana s pojedinačnim prodavačem, zapravo ima tablicu ugrađenu u tablicu. Primjetite kako se Office i OfficeNumber ponavljaju s "Austin Downtown". Što ako se promijeni broj telefona ureda? Trebali biste ažurirati cijeli skup podataka za jedan dio informacija koji mijenja, što nikada nije dobra stvar. Ova polja trebaju biti premještena u vlastiti stol.

Ova vrsta dizajna također vam daje mogućnost dodavanja dodatnih informacija u Office tablicu bez stvaranja noćne more zbrke u tablici prodavača. Zamislite koliko bi posla bilo jednostavno pratiti uličnu adresu, grad, državu i poštanski broj ako su sve te informacije bile u tablici prodavača!

Pogreška u bazi podataka # 3: Stavljanje dva ili više dijelova informacija u jedno polje

Ugrađivanje informacija o uredu u tablicu prodajnih osoba nije bio jedini problem s tom bazom podataka. Polje adrese sadržavalo je tri informacije: ulica, grad i država. Svako polje u bazi podataka trebalo bi sadržavati samo jedan podatak. Kada imate više dijelova informacija u jednom polju, može biti teže upiti bazu podataka radi informacija.

Na primjer, što ako želimo pokrenuti upit na svim prodajnim osobama iz Austina? Trebali bismo pretraživati ​​unutar adresnog polja, što je ne samo neučinkovito, već može vratiti loše informacije. Uostalom, što se događa ako je netko živio na ulici Austin u Portlandu, Oregon?

Evo što bi stol trebao izgledati:

Ovdje treba zapamtiti nekoliko stvari. Prvo, čini se da su "Address1" i "Address2" ispod pogreške ponavljajućih polja.

Međutim, u ovom se slučaju odnose na zasebne podatke koji se izravno odnose na prodajnu osobu, a ne na ponavljajuću skupinu podataka koji bi trebali ići u svoju tablicu.

Također, kao bonus pogreška kako biste izbjegli, obavijestite kako je formatiranje telefonskog broja izvučeno iz stola. Trebali biste izbjegavati spremanje oblika polja kada je to moguće. U slučaju telefonskih brojeva, ljudi na više načina mogu napisati telefonski broj: 215-555-5858 ili (215) 555-5858. To bi potraţilo prodajnu osobu njihovim telefonskim brojem ili otežavalo pretraživanje prodajnih ljudi u istom području.

Pogreška u bazi podataka # 4: Ne koristite ispravan primarni ključ

U većini slučajeva želite upotrijebiti automatski broj za povećavanje ili neki drugi generirani broj ili alfanumerički broj za primarnu tipku. Trebali biste izbjegavati upotrebu bilo kakvih stvarnih informacija za primarnu tipku, čak i ako zvuči da bi to učinio dobar identifikator.

Na primjer, svatko od nas ima svoj osobni broj socijalne sigurnosti, tako da bi se broj socijalnog osiguranja za bazu zaposlenika mogao činiti kao dobra ideja. No, iako je rijetko, moguće je da se i broj socijalnog osiguranja promijeni, a mi nikada ne želimo da se naš primarni ključ promijeni.

I to je problem upotrebe stvarnih informacija kao ključne vrijednosti. Može se promijeniti.

Pogreška baze podataka # 5: Ne upotrebljavajući Konvenciju o imenima

To možda neće zvučati kao velika stvar kada najprije započnete s projektiranjem svoje baze podataka, ali kada dođete do točke upita upita o bazi podataka da biste dohvatili informacije, konvencija o imenovanju pomoći će vam kako zapamtite nazive polja.

Zamislite koliko je teži proces taj ako se imena pohranjuju kao FirstName, LastName u jednoj tablici i first_name, last_name u drugoj tablici.

Dvije najpopularnije konvencije o imenovanju kapitaliziraju prvo slovo svake riječi u polju ili razdvajaju riječi pomoću podcrtava. Možda ćete vidjeti i neke programere koji kapitaliziraju prvo slovo svake riječi osim prve riječi: firstName, lastName.

Također ćete htjeti odlučiti o upotrebi pojedinačnih naziva tablica ili naziva tablica množine. Je li tablica narudžbe ili tablica narudžbi? Je li tablica kupaca ili tablica kupaca? Opet, ne želite biti zaglavljeni sa stolom Order i tablicom Kupaca.

Konvencija o imenovanju koju odaberete nije važna kao proces odabira i pridržavanja konvencije o imenovanju.

Pogreška u bazi podataka # 6: nepravilno indeksiranje

Indeksiranje je jedna od najtežih stvari koje treba postići, posebno za one nove u dizajnu baze podataka. Svi primarni ključevi i strani ključevi trebaju biti indeksirani. To su ono što povezuju tablice zajedno pa bez indeksa vidjet ćete vrlo slabu izvedbu iz svoje baze podataka.

Ali ono što je prečesto propušteno su druga polja. Ovo su polja "WHERE". Ako često ograničavate pretraživanje pomoću polja WHERE klauzule, želite razmisliti o stavljanju indeksa na to polje. Međutim, ne želite pretjerano indeksirati stol, što također može povrijediti izvedbu.

Kako odlučiti? Ovo je dio umjetnosti dizajna baze podataka. Nema tvrdih ograničenja koliko indeksa trebate staviti na stol. Prije svega, želite indeksirati bilo koje polje koje se često koristi u WHERE klauzuli. Pročitajte više o ispravnom indeksiranju baze podataka.