Algemene foute gemaak in databasisontwerp

Of u nou werk met 'n databasis wat honderde rekords of miljoene rekords bevat, behoorlike databasisontwerp is altyd belangrik. Dit sal nie net die inligting makliker maak nie, maar dit sal ook die databasis in die toekoms vergemaklik. Ongelukkig is dit maklik om in 'n paar valle te val wat dinge in die toekoms moeilik kan maak.

Daar is heelwat boeke wat geskryf word oor die normalisering van 'n databasis, maar as jy eenvoudig hierdie algemene foute vermy, sal jy op die regte pad wees vir goeie databasisontwerp.

Databasis fout # 1: Herhaling van velde in 'n tabel

'N Basiese reël vir goeie databasisontwerp is om herhalende data te herken en om die herhalende kolomme in hul eie tabel te plaas. Herhalende velde in 'n tabel is algemeen vir diegene wat uit die wêreld van sigblaaie gekom het, maar alhoewel sigblaaie geneig is om plat deur ontwerp te wees, moet databasisse relasioneel wees. Dit is soos om van 2D na 3D te gaan.

Gelukkig is herhalende velde gewoonlik maklik om te sien. Kyk net na hierdie tabel:

Wat gebeur as 'n bestelling vier produkte bevat? Ons sal 'n ander veld by die tafel moet voeg om meer as drie produkte te ondersteun. En as ons 'n kliënt aansoek om die tafel gebou het om ons te help om data in te voer, moet ons dit dalk verander met die nuwe produkveld. En hoe vind ons al die bestellings met Jellybeans in die bestelling? Ons sal gedwing word om elke produkveld in die tabel te vra met 'n SQL-stelling wat dalk lyk: SELECT * FROM Products WHERE Product1 = 'Jelly Beans' OF Product2 = 'Jelly Beans' OF Product3 = 'Jelly Beans'.

In plaas daarvan om 'n tafel te hê wat al die inligting bymekaarmaak, moet ons drie tafels hê wat elk 'n duidelike stuk inligting bevat. In hierdie voorbeeld wil ons 'n bestellings tabel hê met inligting oor die bestelling self, 'n Produkte tafel met al ons produkte en 'n ProductOrders-tablet wat produkte aan die bestelling gekoppel het.

Let op hoe elke tafel sy eie unieke ID-veld het. Dit is die primêre sleutel. Ons skakel tabelle aan deur 'n primêre sleutelwaarde as 'n vreemde sleutel in 'n ander tabel te gebruik. Lees meer oor primêre sleutels en vreemde sleutels.

Databasis fout # 2: 'n tabel in 'n tabel inbedek

Dit is nog 'n algemene fout, maar dit staan ​​nie altyd soveel soos herhalende velde uit nie. Wanneer u 'n databasis ontwerp, wil u seker maak dat al die data in 'n tabel op homself betrekking het. Dis soos die kind se spel om te spot wat anders is. As jy 'n piesang, 'n aarbei, 'n perske en 'n televisiestel het, behoort die televisiestasie waarskynlik êrens anders.

Terselfdertyd, as u 'n tafel van verkopers het, moet al die inligting in die tabel spesifiek verband hou met die verkoopsman. Enige ekstra inligting wat nie uniek is aan daardie verkoopspersoneel, kan iewers in u databasis voorkom nie.

Terwyl hierdie tabel lyk, is dit alles verwant aan die individuele verkoopsman, dit het eintlik 'n tafel wat binne die tafel ingebed is. Let op hoe die Kantoor en Kantoornommer herhaal met "Austin Downtown". Wat gebeur as 'n kantoor telefoonnommer verander? Jy sal 'n hele stel data moet opdateer vir 'n enkele stuk inligting wat verander, wat nooit 'n goeie ding is nie. Hierdie velde moet na hul eie tafel verskuif word.

Hierdie tipe ontwerp gee jou ook die geleentheid om bykomende inligting by die kantoortafel by te voeg, sonder om 'n nagmerrie van rommel in die verkooppersoontafel te skep. Stel jou voor hoeveel werk dit sou wees om bloot die straatadres, stad, staat en poskode by te hou as al die inligting in die verkooppersoontafel was!

Databasis fout # 3: Om twee of meer stukke inligting in 'n enkele veld te plaas

Die inbedding van die kantoorinligting in die verkooppersoonstabel was nie die enigste probleem met daardie databasis nie. Die adresveld bevat drie stukke inligting: die straatadres, die stad en die staat. Elke veld in die databasis moet slegs een enkele inligting bevat. As jy meer inligting in 'n enkele veld het, kan dit moeiliker wees om die databasis te vra vir inligting.

Byvoorbeeld, wat as ons 'n navraag op al die verkopers uit Austin wou doen? Ons moet binne die adresveld soek, wat nie net ondoeltreffend is nie, maar kan slegte inligting teruggee. Na alles, wat gebeur as iemand op Austinstraat in Portland, Oregon gewoon het?

Hier is hoe die tafel lyk:

Daar is 'n paar dinge om hier kennis te neem. Eerstens, "Adres1" en "Adres2" lyk onder die herhalende velde fout.

In hierdie geval verwys hulle egter na afsonderlike stukke data wat direk met die verkoopspersoon verband hou, eerder as 'n herhalende groep data wat in sy eie tafel moet gaan.

As 'n bonus fout om te vermy, let ook op hoe die formatering vir die foonnommer uit die tabel gestroop is. U moet vermy om die formaat van die velde te stoor wanneer dit moontlik is. In die geval van telefoonnommers is daar verskeie maniere waarop mense 'n telefoonnommer skryf: 215-555-5858 of (215) 555-5858. Dit sal op soek na 'n verkoopspersoon deur hul foonnommer of soek na verkopers in dieselfde area kode moeiliker.

Databasis fout 4: Gebruik nie 'n korrekte primêre sleutel nie

In die meeste gevalle sal u 'n outomaties toenemende nommer of 'n ander gegenereerde nommer of alfanumeriese vir u primêre sleutel wil gebruik. Jy moet vermy om enige werklike inligting vir die primêre sleutel te gebruik, selfs al lyk dit of dit 'n goeie identifiseerder sou maak.

Byvoorbeeld, ons het elk ons ​​eie individuele sosiale sekerheid nommer, dus die gebruik van die sosiale sekerheid nommer vir 'n werknemer databasis klink dalk 'n goeie idee. Maar terwyl dit skaars is, is dit moontlik dat selfs 'n sosiale sekerheid nommer verander, en ons wil nooit ons primêre sleutel verander nie.

En dit is die probleem met die gebruik van werklike inligting as 'n sleutelwaarde. Dit kan verander.

Databasis Fout # 5: Gebruik nie 'n Naming Convention

Dit lyk dalk nie as 'n groot probleem as jy eers begin met die ontwerp van jou databasis nie, maar sodra jy navrae kry teen die databasis om inligting te herwin, sal 'n naamkonvensie help as jy veldname memoriseer.

Dink net hoeveel moeiliker die proses sou wees as name as Eerste naam, LastName in een tabel en eerste naam, laaste naam in 'n ander tabel gestoor is.

Die twee gewildste naamkonvensies kapitaliseer die eerste letter van elke woord in die veld of skei woorde met behulp van 'n onderstreep. U kan ook sommige ontwikkelaars sien om die eerste letter van elke woord te kapitaliseer, behalwe die eerste woord: eerste naam, laaste naam.

U sal ook besluit om enkelvoudige tabelname of meervoudstabelname te gebruik. Is dit 'n bestelling tabel of 'n bestellings tabel? Is dit 'n kliënt tafel of kliënte tafel? Weereens, jy wil nie vas met 'n bestelling tafel en 'n kliënte tafel.

Die benamingskonvensie wat u kies, is nie so belangrik as die proses om eintlik te kies en aan te hou by 'n benoemingskonvensie nie.

Databasis fout # 6: Onbehoorlike indeksering

Indeksering is een van die moeilikste dinge om reg te kry, veral vir die nuutste by databasisontwerp. Alle primêre sleutels en vreemde sleutels moet geïndekseer word. Dit is wat skakel tabelle saam, dus sonder 'n indeks, sal jy baie swak prestasie uit jou databasis sien.

Maar wat word te dikwels gemis, is die ander velde. Dit is die "WHERE" velde. As jy jou soektog dikwels verlig deur 'n veld in 'n WHERE-klousule te gebruik, wil jy oorweeg om 'n indeks op die veld te plaas. Jy wil egter nie die tabel te veel indekseer nie, wat ook prestasie kan seer.

Hoe om te besluit? Dit is deel van die kuns van databasisontwerp. Daar is geen harde perke op hoeveel indekse jy op 'n tafel moet sit nie. Hoofsaaklik, jy wil enige veld wat dikwels in 'n WHERE-klousule gebruik word, indekseer. Lees meer oor behoorlike indeksering van jou databasis.