Iga kord, kui teile antakse arendajana ülesanne olemasoleva koodi põhjal, peate seisma silmitsi paljude väljakutsetega. Üks neist väljakutsetest - enamasti kõige nõudlikum - hõlmab rakenduse andmemudeli mõistmist.

Tavaliselt seisate silmitsi segaste tabelite, vaadete, veergude, väärtuste, salvestatud protseduuride, funktsioonide, piirangute ja käivitajatega, mille mõistmine võtab teie jaoks kaua aega. Ja kui see on olemas, hakkate märkama paljusid viise, kuidas salvestatud teavet paremaks muuta ja ära kasutada.

Kui olete kogenud arendaja, märkate tõenäoliselt ka asju, mida oleks saanud alguses paremini teha, nimelt disainivigu.

Selles artiklis saate teada mõningatest levinud andmebaaside kujundamise halbadest tavadest, miks need halvad on ja kuidas neid vältida.

Vale tava nr 1: andmete eesmärgi ignoreerimine

Andmed salvestatakse hiljem tarbimiseks ja eesmärk on alati neid kõige tõhusamal viisil salvestada ja kätte saada. Selle saavutamiseks peab andmebaasi kujundaja eelnevalt teadma, mida andmed kujutavad, kuidas neid hankida ja millise kiirusega, milline on nende töömaht (st kui palju andmeid oodatakse) ja lõpuks, kuidas neid kasutatakse ...

Näiteks tööstusinfosüsteemil, kus andmeid kogutakse iga päev käsitsi, ei ole sama andmemudelit kui tööstussüsteemil, kus teave luuakse reaalajas. Miks? Sest kuus on sadade või tuhandete plaatide käsitlemine võrreldes sellega väga erinev hallata neid miljoneid samal perioodil. Disainerid peavad andmebaasi tõhususe ja kasutatavuse säilitamiseks võtma erilisi kaalutlusi, kui andmeside maht peaks olema suur.

Kuid loomulikult pole andmete maht ainus aspekt, mida tuleb arvestada, kuna andmete eesmärk mõjutab ka normaliseerimise taset, andmestruktuuri, kirje suurust ja kogu süsteemi üldist rakendamist.

Seetõttu viib teie loodud andmesüsteemi eesmärgi põhjalik mõistmine kaalumisele andmebaasimootori valiku, kavandatavate üksuste, kirje suuruse ja vormingu ning andmebaasimootori halduspoliitika kohta.

Nende eesmärkide eiramine toob kaasa disaini, mis on oma põhiaspektides vigane, isegi kui see on struktuurilt ja matemaatiliselt õige.

Halb tava nr 2: halb standardimine

Andmebaasi kujundamine ei ole deterministlik ülesanne; Kaks andmebaasikujundajat saavad järgida kõiki antud probleemi normaliseerimise reegleid ja põhimõtteid ning genereerivad enamikul juhtudel erinevad andmekujundused. See on omane tarkvaratehnika loomingulisele olemusele. Siiski on mõned analüüsimeetodid, mis on mõistlikud igal juhul ja nende järgimine on parim viis andmebaasi jõudmiseks, mis toimib kõige paremini.

Vaatamata sellele seisame sageli silmitsi andmebaasidega, mis on loodud lennult, järgimata kõige elementaarsemaid reegleid. Peame olema selged: iga andmebaas tuleb vähemalt normaliseerida kolmandale tavavormile, kuna just see kujundus esindab kõige paremini tema üksusi ja mille jõudlus on päringute ning sisestus-, värskendus- ja kustutuskirjete vahel paremini tasakaalustatud.

Kui puutute kokku tabelitega, mis ei vasta 3NF , 2NF või isegi 1NF kaaluvad nende tabelite ümberkujundamist. Selle nimel tehtud pingutus tasub end ära väga lühikese aja jooksul.

Halb tava nr 3: koondamine

Seotud tihedalt eelmise punktiga, kuna üks neist standardimiseesmärgid on selle vähendamine, koondamine on veel üks halb tava, mis ilmneb väga sageli.

Üleliigsed väljad ja tabelid on arendaja õudusunenägu, kuna suure osa sama teabe ajakohasena hoidmiseks on vaja äriloogikat. See on üldkulud, mida saab vältida, kui tähele järgitakse normeerimisreegleid. Kuigi koondamine võib mõnikord tunduda vajalik, tuleks seda kasutada ainult väga konkreetsetel juhtudel ja see peaks olema selgelt dokumenteeritud, et seda saaks edaspidistes arengutes arvesse võtta.

Koondamise tüüpilised negatiivsed mõjud on ebavajalik andmebaasi suuruse suurenemine, andmed on altid ebajärjekindlusele ja vähendavad andmebaasi efektiivsust, kuid - mis kõige tähtsam - see võib viia andmete korruptsioonini.

Vale tava nr 4: halb viite terviklikkus (piirangud)

Referentsiaalne terviklikkus on üks väärtuslikumaid tööriistu, mida andmebaasimootorid pakuvad, et andmete kvaliteet oleks parim. Kui projekteerimisetapist alates ei rakendata mingeid piiranguid või rakendatakse väga vähe piiranguid, peab andmete terviklikkus sõltuma täielikult äriloogikast, mis muudab need altid inimlikele eksimustele.

Halb tava nr 5: Andmebaasimootori funktsioonide kasutamata jätmine

Kui kasutate a andmebaasimootor , teil on andmete haldamise ülesannete jaoks võimas tarkvara, mis lihtsustab tarkvaraarendust ja tagab, et teave on alati õige, turvaline ja kasutatav. Andmebaasimootor pakub järgmisi teenuseid:

• Vaated, mis pakuvad kiiret ja tõhusat viisi teie andmete vaatamiseks, tavaliselt sünkroonimata viitena, kaotamata andmete õigsust.

• Indeksid, mis aitavad tabelipäringuid kiirendada.

• Lisatud funktsioonid, mis aitavad teavet analüüsida ilma programmeerimiseta.

• Tehingud või lauseplokid, mis muudavad täidetavaid andmeid ja sooritavad või tühistavad (tühistavad), kui juhtub midagi ootamatut, hoides seega teavet püsivalt õiges olekus.

• Lukud, mis tagavad andmete turvalisuse ja korrektsuse tehingute ajal.

• Salvestatud protseduurid, mis pakuvad keerukate andmehaldustoimingute võimaldamiseks ajastamisvõimalusi.

• Funktsioonid, mis võimaldavad keerukaid arvutusi ja andmete teisendamist.

• Piirangud, mis aitavad tagada andmete täpsust ja vältida vigu.

• Käivitajad, mis aitavad toiminguid automatiseerida, kui andmetes esinevad sündmused.

• Optimeerija käsk (käivitamise ajastaja), mis töötab kapoti all, tagades, et iga fraas täidetakse parimal viisil, ja hoides täitmiskavasid edaspidiseks. See on üks parimaid põhjuseid vaadete, salvestatud protseduuride ja funktsioonide kasutamiseks, kuna nende täitmiskavasid hoitakse andmebaasimootoris püsivalt.

Nende võimaluste mittetundmine või ignoreerimine viib arengu äärmiselt ebakindlale teele ja kindlasti tulevaste vigade ja probleemideni.

Halb tava nr 6: komposiitpõhised võtmed

See on vaidluskoht, kuna paljud andmebaaside kujundajad räägivad tänapäeval automaatselt loodud välja kasutamisest ID esmase võtmena esmane kahe või enama välja kombineerimisel määratletud ühendi asemel. Praegu on see määratletud kui 'parim tava' ja ma kipun isiklikult sellega nõustuma.

Kuid see on lihtsalt kokkulepe ja muidugi võimaldab andmebaasimootor võtmeid määratleda liitprimaarid , mis paljude disainerite arvates on vältimatu. Seetõttu on kombineeritud primaarvõtmed, nagu ka koondamise puhul, kujundusotsus.

Pidage siiski meeles, et kui eeldate, et koondtoodud võtmega tabelis on miljoneid ridu, võib liitvõtit juhtiv indeks kasvada punktini, kus toimingu toimimine JUUR see on väga degradeerunud. Sel juhul on palju parem kasutada primaarvõtit ID lihtne, millel on piisavalt kompaktne register ja mis seab unikaalsuse säilitamiseks vajalikud andmebaasimootori piirangud.

Halb tava nr 7: halb indekseerimine

Mõnikord on teil tabel, mida peate paljude veergude jaoks päringuid tegema. Kui tabel kasvab, märkate, et SELECTs nendes veergudes aeglustub. Kui tabel on piisavalt suur, mõtlete loogiliselt luua igale veerule register, mida kasutate selle tabeli juurde pääsemiseks, kuid märkate peaaegu kohe, et SELECTide jõudlus paraneb, kuid langeb INSERT, UPDATE ja DELETE. See on muidugi tingitud asjaolust, et indeksid peavad olema tabeliga sünkroonis, mis tähendab andmebaasimootori jaoks tohutut üldkulusid. See on tüüpiline liigse indekseerimise juhtum, mida saate lahendada mitmel viisil; Näiteks kui kõigil veergudel on ainult üks register, välja arvatud esmane võti, mida kasutate tabeli päringuteks, võib nende veergude sorteerimine kõige tavalisematest kõige vähem kasutatuteks pakkuda paremat toimivust kõigi JUUR rohkem kui üks register veerus.

Teisest küljest viib tabeli olemasolu ilma päringuteta veergudes indeksita, nagu me kõik teame, see viib SELECTide kehva jõudluseni.

Samuti sõltub indeksi efektiivsus mõnikord veeru tüübist; INT-i veergude indeksid näitavad parimat võimalikku toimivust, kuid VARCHARi, DATE'i või DECIMALi indeksid (kui see on mõistlik) ei ole nii tõhusad. See kaalutlus võib viia isegi tabelite ümberkujundamiseni, millele tuleks juurde pääseda parima võimaliku tõhususega.

Seetõttu on indekseerimine alati delikaatne otsus, kuna liiga palju indekseerimist võib olla nii vähe kui liiga vähe ja kuna indekseeritavate veergude andmetüüp mõjutab lõpptulemust suuresti.

Halb tava nr 8: halvad nomenklatuuri konventsioonid

Sellega võitlevad programmeerijad alati olemasoleva andmebaasiga silmitsi seistes: mõistavad, millist teavet sinna tabeli ja veeru nimede järgi salvestatakse, sest muud võimalust pole sageli.

Tabeli nimi peaks kirjeldama, millist üksust see sisaldab, ja iga veeru nimi peaks kirjeldama, millist teavet see esindab. See on lihtne, kuid see hakkab keeruliseks muutuma, kui tabelid peavad olema omavahel seotud. Nimed hakkavad segaseks ja hullemaks minema, kui segi ajada nimetamiskonventsioone ebaloogiliste reeglitega (näiteks näiteks 'veeru nimi peab olema 8 tähemärki või vähem'). Lõpptulemus on see, et andmebaas muutub loetamatuks.

Seetõttu a nimetamise konventsioon seda on alati vaja, kui eeldatakse, et andmebaas püsib ja areneb koos selle toetatava rakendusega. Siin on mõned juhised sisutiheda, lihtsa ja loetava versiooni loomiseks:

• Tabeli või veeru nime suurusele pole piiranguid. Parem on kirjeldav nimi kui akronüüm, mida keegi ei mäleta ega mõista.

• Samadel nimedel on sama tähendus. Vältige sama nimega, kuid eri tüüpi või tähendusega väljade olemasolu; see tekitab varem või hiljem segadust.

• Kui see pole vajalik, ärge olge üleliigne. Näiteks tabelis 'Üksus' ei pea olema veerge nagu 'Kauba nimi', 'Kauba hind' või sarnaseid nimesid; Piisab 'Nimi' ja 'Hind'.

• Olge andmebaasimootorile reserveeritud sõnadega ettevaatlik. Kui veeru nimi peab olema 'Index', mis on SQL-i reserveeritud sõna, proovige kasutada mõnda muud, näiteks 'IndexNumber'.

• Kui jääte lihtsa primaarvõtme (automaatselt genereeritud ühe täisarvu) reegli juurde, nimetage see igas tabelis 'Id'.

• Kui liitute mõne teise tabeliga, määrake nõutav võõrvõti täisarvuna, mille nimi on 'Id', millele järgneb ühendatud tabeli nimi (nt IdItem).

• Kui piirangud on nimetatud, kasutage piirangut kirjeldavat eesliidet (näiteks 'PK' või 'FK'), millele järgneb kaasatud tabeli või tabelite nimi. Muidugi aitab alakriipsude ('_') säästlik kasutamine muuta asjad paremini loetavaks.

• Indeksite nimetamiseks kasutage eesliidet 'IDX', millele järgneb tabeli nimi ja indeksi veerg või veerud. Kui indeks on ainulaadne ja vajadusel alla joonitud, kasutage ka ees- või järelliidet 'UNIQUE'.

Internetis on palju andmebaaside nimetamise juhiseid, mis valgustavad seda andmebaaside kujundamise väga olulist aspekti, kuid nende põhiliste toimingutega saate vähemalt lugeda loetavale andmebaasile juurde. Siinkohal pole oluline nimetamisjuhiste suurus ega keerukus, vaid järjekindlus nende järgimisel!

Mõned lõppvaatlused

Andmebaasi ülesehitus on teadmiste ja kogemuste kombinatsioon; Tarkvaratööstus on selle loomisest alates palju arenenud. Õnneks on abiks piisavalt teadmisi andmebaaside kujundajatele parimate tulemuste saavutamiseks.

On häid suunised andmebaasi kujundamisel kogu Internetis, samuti halvad harjumused Y asjad, mida vältida andmebaasi kujundamisel. Lihtsalt vali ja kleepige.

Ja ärge unustage, et ainult katsetamise, vigade ja õnnestumiste kaudu õpite, nii et jätkake ja alustage kohe.