Tietokantojen suunnittelussa tehdyt yleiset virheet

Olipa kyseessä tietokanta, jolla on satoja tietueita tai miljoonia tietueita, asianmukainen tietokannan suunnittelu on aina tärkeää. Sen ansiosta tiedon hakeminen on paljon helpompaa, ja se myös yksinkertaistaa tietokannan laajentamista tulevaisuudessa. Valitettavasti on helppo pudota muutamia ansoja, jotka voivat vaikeuttaa tulevaisuudessa.

Tietokannan normalisointiin on kirjoitettu koko kirjoja, mutta jos yksinkertaisesti vältät nämä yleiset virheet, sinä olet oikealla tiellä hyvästä tietokantasuunnittelusta.

Tietokantahäiriö # 1: Toistetaan kentät taulukossa

Perussuomisääntö, jolla hyvä tietokannan suunnittelu on tunnistaa toistuvat tiedot ja laittaa nämä toistuvat sarakkeet omaan taulukkoonsa. Taulukon toistuvat kentät ovat tavallisia niille, jotka ovat tulleet taulukkolaskennan maailmasta, mutta laskentataulukoiden taipumus olla taipuisa suunnittelussa, tietokantojen tulisi olla suhteellisia. Se on kuin siirtyminen 2D: stä 3D: ään.

Onneksi toistuvat kentät ovat yleensä helposti nähtävissä. Katsokaa vain tätä taulukkoa:

Mitä tapahtuu, kun tilaus sisältää neljä tuotetta? Meidän olisi lisättävä uusi kenttä taulukkoon, jotta voimme tukea yli kolmea tuotetta. Ja jos olemme rakentaneet taulukon ympärille sovellettavan asiakassovelluksen, jotta voimme syöttää tietoja, saatamme joutua muuttamaan sitä uuden tuotekentän avulla. Ja miten löydämme kaikki tilaukset Jellybeansin kanssa järjestyksessä? Meidän olisi pakko kyselyn jokaisen tuotekentän taulukossa SQL-käskyä, joka saattaa näyttää: SELECT * FROM Tuotteet WHERE Product1 = 'Jelly Beans' TAI Product2 = 'Jelly Beans' TAI Product3 = 'Jelly Beans'.

Sen sijaan, että olisi olemassa yksi taulukko, joka kerää kaikki tiedot yhteen, meillä pitäisi olla kolme taulukkoa, joista jokaisella on erillinen tieto. Tässä esimerkissä haluamme Tilaa-taulukon, jossa on tietoja itse tilauksesta, Products-taulukosta kaikkien tuotteiden ja ProductOrders-tabletin kanssa, jotka liittävät tuotteita tilaukseen.

Huomaa, miten jokaisella taulukolla on oma yksilöllinen tunnuskenttä. Tämä on ensisijainen avain. Liitämme taulukoita käyttämällä ensisijaista avainarvoa vierasnäppäimena toisessa taulukossa. Lue lisää ensisijaisista avaimista ja ulkomaisista avaimista.

Tietokannan vika # 2: taulukon upottaminen taulukkoon

Tämä on toinen yleinen virhe, mutta se ei aina muistuta yhtä paljon kuin toistuvat kentät. Kun suunnittelet tietokantaa, haluat varmistaa, että kaikki taulukon tiedot liittyvät itseensä. Se on kuin lapsen peli siitä, kun huomaat, mikä on erilainen. Jos sinulla on banaani, mansikka, persikka ja televisio, televisio todennäköisesti kuuluu muualle.

Samoista linjoista, jos sinulla on myyntihenkilöiden taulukko, kaikkien kyseisessä taulukossa olevat tiedot koskevat erityisesti kyseistä myyntiä. Kaikki ylimääräiset tiedot, jotka eivät ole ainutlaatuisia kyseiselle myyjälle, voivat kuulua muualle tietokantaan.

Vaikka tämä taulukko saattaa näyttää siltä, ​​että se liittyy kaikkiin yksittäisiin myyjiin, sillä on itse asiassa taulukon sisällä oleva taulukko. Huomaa, miten Office ja OfficeNumber toistuvat "Austin Downtown" -keskuksessa. Entä jos toimiston puhelinnumero muuttuu? Sinun olisi päivitettävä koko joukko tietoja yhdestä tiedostomuodosta, mikä ei ole koskaan hyvä asia. Nämä kentät on siirrettävä omaan taulukkoon.

Tämäntyyppinen muotoilu antaa myös mahdollisuuden lisätä tietoja Office-taulukkoon luomatta myyntihenkilön taulukon painajaisia. Kuvittele, kuinka paljon työtä se olisi yksinkertaisesti seurata katuosoitetta, kaupunkia, valtiota ja postinumeroa, jos kaikki nämä tiedot olivat myyntihenkilötaulukossa!

Tietokannan vika # 3: Kahden tai useamman tiedon lisääminen yhdelle kentälle

Toimistotietojen upottaminen myyntihenkilötaulukkoon ei ollut ainoa ongelma kyseisen tietokannan kanssa. Osoitekenttä sisälsi kolme tietoa: katuosoite, kaupunki ja valtio. Tietokannan kullakin kentällä tulisi olla vain yksi ainoa tieto. Kun yksittäisillä kentillä on useita tietoja, tietokannasta voi olla vaikeampi kysyä tietoa.

Esimerkiksi, jos halusimme hakea kyselyä kaikista myyjistä Austinista? Meidän olisi etsiä osoitekentässä, joka ei ole vain tehottomampi, mutta voi palauttaa huonot tiedot. Loppujen lopuksi, mitä tapahtuu, jos joku asui Austin Streetissä Portlandissa, Oregonissa?

Tässä taulukon pitäisi näyttää:

Tässä on muutamia asioita. Ensinnäkin "Address1" ja "Address2" näyttävät kuuluvan toistuvan kentän virheeseen.

Kuitenkin tässä tapauksessa ne viittaavat erillisiin tietoihin, jotka liittyvät suoraan myyjään eikä toistuvaan tietoryhmään, joka pitäisi mennä omaan taulukkoonsa.

Myös vältettävänä bonusvirheenä huomaa, kuinka puhelinnumeron muotoilu on poistettu taulukosta. Sinun tulisi välttää kenttien muotoilun säilyttäminen aina kun se on mahdollista. Puhelinnumeroissa on useita tapoja, joilla ihmiset voivat kirjoittaa puhelinnumeron: 215-555-5858 tai (215) 555-5858. Tämä tekisi etsimään myyjää puhelinnumeronsa avulla tai etsimällä myynnin ihmisiä samassa alueosoituksessa vaikeammaksi.

Tietokannan vika # 4: Ei oikeaa ensisijaista näppäintä

Useimmissa tapauksissa haluat käyttää ensisijaisesti käyttämääsi automaattisen lisäysnumeron tai jonkin muun vastaavan numeron tai aakkosnumeerisen numeron. Sinun tulisi välttää ensisijaisten avainten käyttämistä varsinaisista tiedoista, vaikka kuulisikin, että se tekisi hyvän tunnisteen.

Esimerkiksi meillä kaikilla on oma yksilöllinen sosiaaliturvatunnus, joten henkilötietokannan sosiaaliturvatunnus voi kuulostaa hyvältä. Mutta harvoin on mahdollista, että jopa sosiaaliturvatunnus muuttuu, emmekä koskaan halua, että ensisijainen avaimemme muuttuu.

Ja tämä on se ongelma, että varsinaista tietoa käytetään tärkeänä arvona. Se voi muuttua.

Tietokannan virhe 5: ei nimeämissopimusta

Tämä ei ehkä vaikuta suurelta, kun aloitat tietokonesovelluksen suunnittelun, mutta kun pääset tietokantojen tietokannoista kyselyyn, nimeämiskäytäntö auttaa sinua tallentamaan kenttien nimet.

Kuvitelkaa, kuinka paljon vaikeampaa prosessi olisi, jos nimet tallennettiin nimellä FirstName, LastName yhdessä taulukossa ja first_name, last_name toisessa taulukossa.

Kaksi suosituinta nimeämiskäytäntöä hyödyntävät jokaisen sanan ensimmäistä kirjainta kentässä tai erotetaan sanoja käyttämällä alaviivaa. Saatat myös nähdä, että jotkut kehittäjät hyödyntävät jokaisen sanan ensimmäistä kirjainta lukuunottamatta ensimmäistä sanaa: firstName, lastName.

Haluat myös päättää yksittäisten taulukkojen tai monien taulukkonimien käytöstä. Onko tilaustaulukko vai tilaus-taulukko? Onko asiakaspöytä tai asiakkaiden taulukko? Jälleen et halua olla jumissa Order-taulukon ja asiakkaiden taulukon kanssa.

Valitsemasi nimeämiskokous ei ole yhtä tärkeä kuin nimeämiskäytännön valintamenettely ja siihen sitoutuminen.

Tietokannan virhe 6: virheellinen indeksointi

Indeksointi on yksi vaikeimmista asioista, varsinkin uusille tietokannan suunnittelulle. Kaikki ensisijaiset avaimet ja vieraat avaimet on indeksoitava. Nämä ovat linkit taulukoita yhteen, joten ilman indeksiä, sinun on erittäin huono suorituskyky tietokannasta.

Mutta liian usein jääneet ovat muita aloja. Nämä ovat WHERE-kentät. Jos aiot usein pienentää hakua kenttään WHERE-lauseketta, haluat ajatella hakemiston sijoittamista kyseiselle kentälle. Et kuitenkaan halua indeksoida liikaa taulukkoa, joka voi myös vahingoittaa suorituskykyä.

Miten päättää? Tämä on osa tietokannan suunnittelun taidetta. Ei ole kovia rajoja, kuinka monta indeksiä haluat laittaa pöytään. Ensisijaisesti haluat indeksoida kentän, jota käytetään usein WHERE-lausekkeessa. Lue lisää tietokannan oikeasta indeksoinnista.