Uobičajene greške nastale u dizajnu baze podataka

Bez obzira da li radite sa bazom podataka koja sadrži stotine zapisa ili miliona zapisa, pravi dizajn baze podataka je uvijek važan. Ne samo da će olakšati pronalaženje informacija, već će i pojednostaviti širenje baze podataka u budućnosti. Nažalost, lako je pasti u nekoliko zamki koje mogu u budućnosti otežati stvari.

Postoje čitave knjige o predmetu normalizacije baze podataka, ali ako jednostavno izbegnete ove uobičajene greške, bićete na pravom putu do dobrog dizajna baze podataka.

Greška baze podataka # 1: Ponavljanje polja u tabeli

Osnovno pravilo za dobar dizajn baze podataka je prepoznavanje ponavljanja podataka i stavljanje tih ponavljajućih kolona u svoju stolu. Ponavljanje polja u tabeli je uobičajeno za one koji su došli iz sveta tabličnih tabaka, ali dok su tablice često dizajnirane, baze podataka bi trebale biti relacijske. To je kao da idete od 2D do 3D.

Na sreću, ponavljana polja su obično lako prepoznati. Samo pogledajte ovu tabelu:

OrderID Product1 Product2 Product3
1 Plišani medvjedići Žele bombone
2 Žele bombone

Šta se događa kada porudžbina sadrži četiri proizvoda? Trebali bismo dodati još jedno polje na tablu kako bismo podržali više od tri proizvoda. I ako smo izgradili klijentsku aplikaciju oko table kako bi nam pomogli da unosimo podatke, možda ćemo morati da je modifikujemo novim poljem proizvoda. I kako da nađemo sve narudžbe sa Jellybeansom u redosledu? Bićemo primorani da upitamo svako polje proizvoda u tablici sa SQL izrazom koji može izgledati: SELECT * FROM Products WHERE Product1 = 'Jelly Beans' ILI Product2 = 'Jelly Beans' ILI Product3 = 'Jelly Beans'.

Umjesto da imamo jedan sto koji sadrži sve informacije zajedno, trebali bi imati tri tabele, od kojih svaka sadrži različite informacije. U ovom primjeru, želeli bi tablicu narudžbine sa informacijama o samoj narudžbi, tabelama proizvoda sa svim našim proizvodima i ProductOrders tableta koja je povezala proizvode sa porudžbinom.

OrderID CustomerID Datum naloga Ukupno
1 7 1/24/17 19.99
2 9 1/25/17 24.99
ProductID Proizvod Count
1 Plišani medvjedići 1
2 Žele bombone 100
ProductOrderID ProductID OrderID
101 1 1
102 2 1

Obratite pažnju na to kako svaka tabela ima svoje jedinstveno ID polje. Ovo je primarni ključ. Povezujemo tabele koristeći vrednost primarnog ključa kao inostrani ključ u drugoj tabeli. Pročitajte više o primarnim ključevima i stranim ključevima.

Greška baze podataka broj 2: ubacivanje tabele u tabele

Ovo je još jedna uobičajena greška, ali se ne ističe uvek onoliko koliko se ponavljajuća polja. Kada dizajnirate bazu podataka, želite se uveriti da se svi podaci u tabeli odnose na samu sebe. To je kao dječja igra o otkrivanju onoga što je drugačije. Ako imate bananu, jagode, breskvu i televizor, televizor verovatno pripada negde drugde.

Sa istim redosledom, ako imate tablicu prodavaca, sve informacije iz te tabele trebaju se posebno odnositi na tu osobu prodaje. Svaka dodatna informacija koja nije jedinstvena za tu osobu prodaje može pripadati negde drugde u vašoj bazi podataka.

SalesID Prvo Poslednji Adresa Telefonski broj Ured OfficeNumber
1 Sam Elliot 118 Main St, Austin, TX (215) 555-5858 Austin Downtown (212) 421-2412
2 Alice Smith 504 2nd Street, Njujork, Njujork (211) 122-1821 New York (East) (211) 855-4541
3 Džo Župnija 428 Aker St, Austin, TX (215) 545-5545 Austin Downtown (212) 421-2412

Iako ova tabela može izgledati kao da je sve povezana sa pojedinačnim prodavačem, ona zapravo ima tabelu ugrađenu u tabelu. Obratite pažnju kako Office i OfficeNumber ponavljaju sa "Austin Downtown". Šta ako se telefonski broj telefona promeni? Trebalo bi da ažurirate čitav niz podataka za jedan pojedinačni deo promene informacija, što nikada nije dobra stvar. Ova polja trebaju biti premeštena na svoju stolu.

SalesID Prvo Poslednji Adresa Telefonski broj OfficeID
1 Sam Elliot 118 Main St, Austin, TX (215) 555-5858 1
2 Alice Smith 504 2nd Street, Njujork, Njujork (211) 122-1821 2
3 Džo Župnija 428 Aker St, Austin, TX (215) 545-5545 1
OfficeID Ured OfficeNumber
1 Austin Downtown (212) 421-2412
2 New York (East) (211) 855-4541

Ovakav dizajn takođe vam daje mogućnost dodavanja dodatnih informacija u tablicu Officea bez stvaranja noćne mase nereda u tabeli prodajnih osoba. Zamislite koliko će raditi jednostavno pratiti ulicnu adresu, grad, državu i poštanski broj ako su sve te informacije bile na stolu za prodaju!

Greška baze podataka # 3: stavljanje dve ili više informacija u jedno polje

Unošenje podataka o kancelariji u tabelu prodajne osobe nije bio jedini problem sa toj bazi podataka. Adresa za adresu sadrži tri informacije: ulicu, grad i državu. Svako polje u bazi podataka treba da sadrži samo jedan podatak. Kada imate više informacija u jednom polju, može postati teže upitati bazu podataka za informacije.

Na primjer, šta ako želimo da pokrenemo upit o svim prodajnim ljudima iz Austina? Trebalo bi da pretražimo unutar polja za adresu, što nije samo neefikasno, već može povratiti loše informacije. Na kraju krajeva, šta se dešava ako neko živi u Austin ulici u Portlandu, u Oregonu?

Evo kako izgleda tablica:

SalesID Prvo Poslednji Adresa 1 Adresa 2 Grad Država Zip Telefon
1 Sam Elliot 118 Main St Austin TX 78720 2155555858
2 Alice Smith 504 2nd St Njujork NY 10022 2111221821
3 Džo Župnija 428 Aker St Apt 304 Austin TX 78716 2155455545

Ovde treba navesti nekoliko stvari. Prvo, "Address1" i "Address2" izgleda da padnu pod grešku ponavljanja polja.

Međutim, u ovom slučaju oni se odnose na odvojene dijelove podataka koji se odnose direktno na prodajno lice, a ne na ponavljajuću grupu podataka koji bi trebali ići u svoju stolu.

Takođe, kao bonus error za izbegavanje, primjetite kako je oblikovanje broja telefona uklonjeno iz tabele. Trebalo bi izbjeći čuvanje formata polja kada je uopće moguće. U slučaju telefonskih brojeva, postoji više načina na koji ljudi upišu telefonski broj: 215-555-5858 ili (215) 555-5858. To bi tražilo osobu prodaje svojim telefonskim brojem ili vršiti pretragu prodavaca u istom području šifre otežavajuće.

Greška baze podataka # 4: Ne koristi tačan primarni ključ

U većini slučajeva, želite primeniti automatski povećavajući broj ili neki drugi generirani broj ili alfanumerički za primarni ključ. Treba izbjeći korištenje bilo kakvih stvarnih informacija za primarni ključ čak i ako zvuči kao da bi napravio dobar identifikator.

Na primjer, svaki od nas ima svoj individualni broj socijalnog osiguranja, tako da korištenje broja socijalnog osiguranja za bazu podataka zaposlenih može izgledati kao dobra ideja. Ali, iako rijetko, moguće je i da se promeni broj socijalnog osiguranja, i nikada ne želimo da se primarni ključ promijeni.

I to je problem pri korišćenju stvarnih informacija kao ključne vrednosti. Može se promeniti.

Greška baze podataka # 5: ne koristi konvenciju imenovanja

Ovo možda ne zvuči kao velika stvar kada prvi put započnete dizajniranje vaše baze podataka, ali kada jednom dođete do tačke upisivanja upita na bazu podataka da biste preuzeli informacije, imanje konvencije za imenovanje će pomoći kada zapamtite imena polja.

Samo zamislite koliko je teži taj proces ako bi se imena čuvala kao FirstName, LastName u jednoj tabeli i first_name, last_name u drugoj tabeli.

Dve najpopularnije konvencije o imenovanju su kapitalizovanje prvog slova svake reči na terenu ili odvajanje riječi pomoću podvučice. Takođe možete videti neke programere koji kapitalizuju prvo slovo svake reči osim prve reči: firstName, lastName.

Takođe ćete želeti da odlučite da koristite imena singularnih tablica ili imena pluralnih tablica. Da li je tabela porudžbina ili tabela naloga? Da li je to stol za klijente ili kupca? Opet, ne želite da se zaglavite sa tablicom za porudžbinu i tablicima kupaca.

Konvencija o imenu koju ste izabrali nije toliko važna kao proces stvarnog izbora i pridržavanja konvencije o imenovanju.

Greška baze podataka # 6: Nepravilno indeksiranje

Indeksiranje je jedna od najtežih stvari koje su u pravu, posebno za one nove u dizajnu baze podataka. Svi primarni ključevi i inostrani ključevi trebaju biti indeksirani. To je ono što povezuje tabele zajedno, tako da bez indeksa, videćete vrlo loše performanse iz vaše baze podataka.

Ali ono što je često nedostaje su druga polja. To su polja "WHERE". Ako često smanjite pretragu pomoću polja u WHERE klauzuli, želite razmisliti o stavljanju indeksa u to polje. Međutim, ne želite previše indeksirati tabelu, koja također može povrijediti performanse.

Kako odlučiti? Ovo je dio dizajna baze podataka. Ne postoje teške granice koliko indeksa treba staviti na stol. Pre svega, želite indeksirati bilo koje polje koje se često koristi u WHERE klauzuli. Pročitajte više o ispravnom indeksiranju vaše baze podataka.