Andmebaasi disainis tehtud üldised vead

Olenemata sellest, kas te töötate andmebaasiga, mis hoiab sadu dokumente või miljoneid kirjeid, on alati asjakohane andmebaasi kujundus. See muudab teabe mitte ainult lihtsamaks, vaid lihtsustab ka andmebaasi laiendamist tulevikus. Kahjuks on lihtne pääseda mõnest lõksust, mis võib tulevikus probleeme keerata.

Andmebaasi normaliseerimise teemal on kirjutatud terveid raamatuid, kuid kui te lihtsalt neid ühiseid vigu vältite, on teil õige andmebaaside kujundus.

Andmebaasi viga # 1: veeru kordamine tabelis

Hea andmebaasi disainilahenduse põhiline reegel on tuvastada andmete kordus ja panna need korduvad veerud oma tabelisse. Tabelis olevad väljad on tavalised tabelite maailmast tulevatele inimestele, kuid kui arvutustabelid kipuvad projekteerimisel olema lamedad, peaksid andmebaasid olema relatsioonilised. See on nagu läheb 2D-st 3D-st.

Õnneks on korduvaid välju tavaliselt lihtne näha. Lihtsalt vaadake seda tabelit:

Mis juhtub, kui tellimus sisaldab neli toodet? Me peame lisama tabeli veel ühe välja, et toetada rohkem kui kolme toodet. Ja kui oleme sisestatud andmete sisestamiseks meile lauaarvuti jaoks loonud kliendirakenduse, peame võib-olla seda uue tooteväljundiga muutma. Ja kuidas me saame Jellybeansi tellimustega kõik tellimused järjekorras? Oleksime sunnitud küsima tabelis kõiki tootevälju SQL-i avaldusega, mis võib välja nägema: SELECT * TOODETEST, KUS Product1 = 'Jelly Beans' VÕI toode2 = 'Jelly Beans' VÕI Toode3 = 'Jelly Beans'.

Selle asemel, et oleks olemas üks tabel, mis koguks kogu teabe kokku, peaks meil olema kolm tabelit, millest igaühel on eraldi informatsioon. Selles näites tahaksime tellimuste tabelit sisaldava teabega tellimuse enda kohta, kõigi meie toodete toodete tabeliga ja tootega seotud toodete tahvelarvutist, mis seostas tooted tellimusega.

Pange tähele, et igal tabelil on oma ainulaadne ID-väli. See on esmane võti. Lingid linkime kasutades primaarvõtme väärtust võõrvõti teises tabelis. Lisateave primaarvõtmete ja võõrkehade kohta.

Andmebaasi viga # 2: tabeli sisestamine tabelisse

See on teine ​​levinud viga, kuid see ei pruugi alati välja paistma üsna sama palju kui korduvaid välju. Andmebaasi kavandamisel peate veenduma, et kõik tabelis olevad andmed on seotud iseendaga. See on nagu selle lapse mäng, mis näitab, mis erineb. Kui teil on banaan, maasikas, virsik ja televiisor, on televiisor tõenäoliselt ka kusagil mujal.

Samamoodi, kui teil on müügiarve tabel, peaks kogu selle tabeli teave olema seotud just selle müügiesindajaga. Mis tahes lisateave, mis ei ole selle müügioperaatori jaoks ainuomane, võivad kuuluda teie andmebaasi kusagil mujal.

Kuigi see tabel võib tunduda nii, et see kõik on seotud üksikute müüjatega, on tabelil tegelikult tabel. Pange tähele, kuidas Office ja OfficeNumber korduvad "Austini kesklinnas". Mis juhtub, kui kontorite telefoninumber muutub? Teil on vaja värskendada kogu andmete kogumit üheainsa teabe vahetamise kohta, mis pole kunagi hea asi. Neid välju tuleb paigutada oma lauale.

Seda tüüpi disain annab teile ka võimaluse lisada Office'i tabelisse täiendavat teavet, luues müügiomanikule tabelisse uimastamise õudusunenägu. Kujutage ette, kui palju tööd oleks lihtsalt jälgida tänava aadressi, linna, riigi ja postiindeksi, kui kogu see teave oleks müügikohtade tabelis!

Andmebaasi viga # 3: kahe või enama teabeosa paigutamine ühele väljale

Kontoriteabe integreerimine müügipersonali tabelisse ei olnud ainus probleem selle andmebaasiga. Aadressiväljal oli kolm teavet: tänava aadress, linn ja riik. Andmebaasi iga välimus peaks sisaldama ainult ühte infot. Kui ühel väljal on mitu tükkainet, võib andmebaas infot küsida.

Näiteks, mis siis, kui me tahame käivitada päring kõikide Austinis asuvate müügimehed? Peaksime otsima aadressiväljale, mis ei ole mitte ainult ebaefektiivne, vaid võib anda halba teabe. Lõppude lõpuks, mis juhtub, kui keegi elas Portlandis Oregoni Austini tänaval?

Siin on tabel peaks välja nägema:

Siin on paar asja. Esiteks tundub, et "Address1" ja "Address2" kuuluvad korduvate väljaannete viga.

Kuid käesoleval juhul viitavad nad üksikutele andmetele, mis on otseselt seotud müügi isikuga, mitte korduvate andmete rühmaga, mis peaks minema oma tabelisse.

Samuti võidakse boonusvea vältimiseks märkida, kuidas telefoni numbri vormindamine tabelist välja jäeti. Peaksite hoiduma väljade vormingu salvestamisest, kui see on üldse võimalik. Telefoninumbrite korral on telefoninumbrit kirjutanud mitmel viisil: 215-555-5858 või (215) 555-5858. See muudaks müügiesindaja otsingu oma telefoninumbri järgi või muudaks sama piirkonnakoodiga müügipersonali otsimise raskemaks.

Andmebaasi viga # 4: ei kasuta õiget esmast võtit

Enamikul juhtudel soovite oma primaarvõtme jaoks kasutada automaatselt järkjärgulist numbrit või mõnda muud loodud numbrit või tähtnumbrit. Peaksite vältima primaarse võtme tegeliku teabe kasutamist, isegi kui tundub, et see oleks hea tunnus.

Näiteks meil on oma individuaalne sotsiaalkindlustuse number, nii et töötajate andmebaasi sotsiaalkindlustuse number võib tunduda hea mõte. Kuigi haruldane on isegi sotsiaalkindlustuse number muutuda, me ei taha, et meie esmane võti muutuks.

Ja see on probleem, kuna võtmeväärtusena kasutatakse tegelikku teavet. See võib muutuda.

Andmebaasi viga # 5: ei kasuta nimekonventsiooni

See võib tunduda suur asi, kui alustasid oma andmebaasi esmakordsel alustamisel, kuid kui jõuate andmebaasi päringute kirjutamispunkti, et teavet otsida, siis aitab nimemuutmiskonventsioon, kui mäletate välja nimesid.

Kujutlege, kui palju see protsess oleks keerulisem, kui nimesid säilitataks kui esimest nime, laua nimesid ühes tabelis ja esimest nime, eelmise nime teises tabelis.

Kaks kõige populaarsemat nimetamise konventsiooni kasutab iga sõna esimest tähte väljale või eraldab sõnu, kasutades alakriipsutamist. Võite näha ka mõnda arendajat, kes kasutavad iga sõna esimest tähte, välja arvatud esimene sõna: firstName, lastName.

Samuti võite otsustada, kas kasutada ainulaadseid laua nimesid või paljusid laua nimesid. Kas see on tellimuste tabel või korralduste tabel? Kas see on kliendi laud või klientide laud? Jällegi ei soovi teid kinni pidada tellimuste tabelist ja klientide tabelist.

Teie valitud nimetamiskonventsioon ei ole nii tähtis, kui isikliku nimetamise konventsiooni valimise ja kinnipidamise protsess.

Andmebaasi viga # 6: sobimatu indekseerimine

Indekseerimine on üks kõige raskemaid asju, mida õigesti saada, eriti uute andmebaaside kujundamisel. Kõik primaarvõtmed ja välisvõti tuleb indekseerida. Need on lingi tabelid koos, seega ilma indeksita näete oma andmebaasist väga halb jõudlust.

Kuid mis on liiga sageli vastamata, on ka teised valdkonnad. Need on "WHERE" väljad. Kui te sageli kavatsete oma otsingut kitsendada, kasutades WHERE-i klausli välju, tahate mõelda indeksi sisestamise kohta selles valdkonnas. Kuid te ei soovi tabeli liigset indekseerimist, mis võib samuti kahjustada esitust.

Kuidas otsustada? See on andmebaaside disaini osa. Mitmeid indekseid, mida peaksite lauale panema, pole raske piirata. Kõigepealt soovite indekseerida mistahes valdkonnas, mida sageli WHERE-klauslina kasutatakse. Lisateave andmebaasi nõuetekohase indekseerimise kohta.