Joka kerta kun kehittäjänä sinulle annetaan tehtävä olemassa olevan koodin perusteella, sinun on kohdattava monia haasteita. Yksi näistä haasteista - useimmiten vaativin - sisältää sovelluksen tietomallin ymmärtämisen.

Yleensä kohtaat hämmentäviä taulukoita, näkymiä, sarakkeita, arvoja, tallennettuja toimintoja, toimintoja, rajoituksia ja laukaisimia, joiden ymmärtäminen kestää kauan. Ja kun heillä on se, alat huomata monia tapoja parantaa ja hyödyntää tallennettuja tietoja.

Jos olet kokenut kehittäjä, huomaat todennäköisesti myös asioita, jotka olisi voitu tehdä paremmin alussa, nimittäin suunnitteluvikoja.

Tässä artikkelissa opit joistakin yleisistä huonoista tietokannan suunnittelukäytännöistä, miksi ne ovat huonoja ja miten voit välttää ne.

Huono käytäntö # 1: Tietojen tarkoituksen ohittaminen

Tiedot tallennetaan kulutettavaksi myöhemmin, ja tavoitteena on aina tallentaa ja noutaa ne tehokkaimmalla tavalla. Tämän saavuttamiseksi tietokannan suunnittelijan on tiedettävä etukäteen, mitä tiedot edustavat, miten ne hankitaan ja millä nopeudella, mikä on niiden toimintamäärä (eli kuinka paljon tietoja odotetaan) ja lopuksi miten niitä käytetään .

Esimerkiksi teollisella tietojärjestelmällä, jossa tietoja kerätään manuaalisesti päivittäin, ei ole samaa tietomallia kuin teollisella järjestelmällä, jossa tiedot tuotetaan reaaliajassa. Miksi? Koska on hyvin erilaista käsitellä satoja tai tuhansia levyjä kuukaudessa verrattuna hallita miljoonia heistä samana ajanjaksona. Suunnittelijoiden on kiinnitettävä erityistä huomiota tietokannan tehokkuuden ja käytettävyyden ylläpitämiseen, jos tietomäärät ovat suuria.

Tietenkin tietomäärä ei kuitenkaan ole ainoa huomioitava näkökohta, koska tietojen tarkoitus vaikuttaa myös normalisointitasoon, tietorakenteeseen, tietueen kokoon ja koko järjestelmän yleiseen toteutukseen.

Siksi luotavan tietojärjestelmän tarkoituksen perusteellinen ymmärtäminen johtaa harkintaan tietokannan moottorin valinnasta, suunniteltavista kokonaisuuksista, tietueen koosta ja muodosta sekä tietokannan moottorin hallintakäytännöistä.

Näiden tavoitteiden huomiotta jättäminen johtaa malleihin, jotka ovat virheellisiä perusasioissaan, vaikka ne olisivatkin rakenteellisesti ja matemaattisesti oikeita.

Huono käytäntö nro 2: Huono standardointi

Tietokannan suunnittelu ei ole deterministinen tehtävä; Kaksi tietokannan suunnittelijaa voi noudattaa kaikkia tietyn ongelman normalisointisääntöjä ja -periaatteita ja tuottaa useimmissa tapauksissa erilaisia ​​tietosuunnitelmia. Tämä on luontaista ohjelmistotuotannon luonteelle. On kuitenkin joitain analyysitekniikoita, jotka ovat järkeviä kussakin tapauksessa, ja niiden noudattaminen on paras tapa käyttää parhaimmillaan toimivaa tietokantaa.

Tästä huolimatta kohtaamme usein tietokantoja, jotka on suunniteltu lennossa, noudattamatta normalisoinnin perussääntöjä. Meidän on oltava selkeitä: jokainen tietokanta on ainakin normalisoitava kolmannelle normaalille muodolle, koska se on muotoilu, joka edustaa parhaiten sen kokonaisuuksia ja jonka suorituskyky tasapainotetaan paremmin kyselyjen ja insert-update-delete-tietueiden välillä.

Jos törmäät taulukoihin, jotka eivät täytä 3NF , 2NF tai jopa 1NF, harkitse näiden taulukoiden uudelleensuunnittelua. Tähän tekemäsi vaivaa kannattaa hyvin lyhyessä ajassa.

Huono käytäntö # 3: redundanssi

Liittyy läheisesti edelliseen kohtaan, koska yksi standardointitavoitteet on vähentää sitä, irtisanominen on toinen huono käytäntö, joka esiintyy hyvin usein.

Redundantit kentät ja taulukot ovat kehittäjän painajaisia, koska ne edellyttävät liiketoimintalogiikkaa pitääkseen suuren osan samoista tiedoista ajan tasalla. Tämä on yleiskustannus, joka voidaan välttää, jos normalisointisääntöjä noudatetaan kirjaimessa. Vaikka irtisanominen saattaa joskus tuntua tarpeelliselta, sitä tulisi käyttää vain hyvin erityistapauksissa ja se olisi dokumentoitava selkeästi, jotta se voidaan ottaa huomioon tulevassa kehityksessä.

Tyypilliset redundanssin negatiiviset vaikutukset ovat tarpeeton tietokannan koon kasvu, tiedot ovat alttiita epäjohdonmukaisuuksille ja heikentävät tietokannan tehokkuutta, mutta - mikä tärkeintä - se voi johtaa tietojen korruptioon.

Huono käytäntö nro 4: Huono viitteellinen eheys (rajoitteet)

Viitteellinen eheys on yksi arvokkaimmista työkaluista, joita tietokantamoottorit tarjoavat tietojen laadun säilyttämiseksi parhaimmillaan. Jos mitään rajoituksia tai hyvin vähän rajoituksia ei toteuteta suunnitteluvaiheesta alkaen, tietojen eheyden on oltava täysin riippuvainen liiketoimintalogiikasta, mikä tekee niistä alttiita inhimillisille virheille.

Huono käytäntö # 5: Tietokannan moottorin ominaisuuksien hyödyntämättä jättäminen

Kun käytät a tietokantamoottori , sinulla on tehokas ohjelmisto tiedonhallintatehtäviisi varten, mikä yksinkertaistaa ohjelmistokehitystä ja varmistaa, että tiedot ovat aina oikeita, turvallisia ja käyttökelpoisia. Tietokantamoottori tarjoaa palveluja, kuten:

• Näkymät, jotka tarjoavat nopean ja tehokkaan tavan tarkastella tietojasi, yleensä synkronoimatta viitetarkoituksessa menettämättä tietojen oikeellisuutta.

• Hakemistot, jotka auttavat nopeuttamaan taulukon kyselyjä.

• Lisätyt toiminnot, jotka auttavat analysoimaan tietoja ilman ohjelmointia.

• Tapahtumat tai lauseiden lohkot, jotka muuttavat suoritettua dataa ja sitoutuvat tai peruuttavat (palautuvat), jos tapahtuu jotain odottamatonta, jolloin tiedot pysyvät pysyvästi oikeassa tilassa.

• Lukot, jotka pitävät tiedot turvassa ja oikeina tapahtumien aikana.

• Tallennetut menettelyt, jotka tarjoavat ajoitusominaisuudet monimutkaisten tiedonhallintatehtävien mahdollistamiseksi.

• Toiminnot, jotka mahdollistavat hienostuneet laskelmat ja tiedonmuunnokset.

• Rajoitukset, jotka auttavat varmistamaan tietojen paikkansapitävyyden ja välttävät virheitä.

• Käynnistimet, jotka auttavat automatisoimaan toimia, kun tiedoissa tapahtuu tapahtumia.

• Konepellin alla toimiva Optimizer-komento (suorituksen ajoitin), joka varmistaa, että jokainen lause suoritetaan parhaalla mahdollisella tavalla, ja pitää toteutussuunnitelmat tulevia tilanteita varten. Tämä on yksi parhaista syistä käyttää näkymiä, tallennettuja toimintatapoja ja toimintoja, koska niiden toteutussuunnitelmia ylläpidetään pysyvästi tietokantamoottorissa.

Näiden ominaisuuksien tietämättä jättäminen tai huomiotta jättäminen johtaa kehityksen äärimmäisen epävarmalla tiellä ja varmasti tuleviin virheisiin ja ongelmiin.

Huono käytäntö # 6: Yhdistetyt ensisijaiset avaimet

Tämä on kiistanalainen asia, kuten monet tietokannan suunnittelijat puhuvat nykyään automaattisen kentän käyttämisestä Henkilötunnus ensisijainen ensisijaisena avaimena yhdisteen sijaan, joka määritetään yhdistämällä kaksi tai useampia kenttiä. Tämä on tällä hetkellä määritelty 'parhaaksi käytännöksi', ja minulla on tapana olla samaa mieltä siitä.

Tämä on kuitenkin vain käytäntö, ja tietenkin tietokantamoottori sallii avainten määrittelyn yhdistetyt esivaalit , jota monet suunnittelijat pitävät väistämättöminä. Siksi, kuten redundanssilla, yhdistetyt pääavaimet ovat suunnittelupäätös.

Muista kuitenkin, että jos oletat, että taulukossa, jossa on yhdistetty ensisijainen avain, on miljoonia rivejä, yhdistettyä avainta ohjaava indeksi voi kasvaa pisteeseen, jossa operaation suorituskyky JULMA se on hyvin hajonnut. Siinä tapauksessa on paljon parempi käyttää ensisijaista avainta Henkilötunnus yksinkertainen, jolla on riittävän kompakti indeksi ja joka asettaa tarvittavat tietokantamoduulin rajoitteet ainutlaatuisuuden ylläpitämiseksi.

Huono käytäntö # 7: Huono indeksointi

Joskus sinulla on taulukko, joka sinun on kysyttävä monista sarakkeista. Kun taulukko kasvaa, huomaat, että näiden sarakkeiden SELECTit hidastuvat. Jos taulukko on riittävän suuri, ajattelet loogisesti luoda hakemisto jokaiselle sarakkeelle, jota käytät tämän taulukon käyttämiseen, mutta huomaat melkein heti, että SELECTsin suorituskyky paranee, mutta INSERT, UPDATE ja DELETE pudota. Tämä johtuu tietysti siitä, että indeksit on pidettävä synkronoituna taulukon kanssa, mikä tarkoittaa tietokannan moottorille valtavia yleiskustannuksia. Tämä on tyypillinen liiallisen indeksoinnin tapaus, jonka voit ratkaista monella tapaa; Esimerkiksi jos kaikissa sarakkeissa on vain yksi hakemisto, lukuun ottamatta ensisijaista avainta, jota käytät taulukon kyselyyn, näiden sarakkeiden lajitteleminen eniten käytettyihin vähiten voi tarjota paremman suorituskyvyn JULMA kuin yksi hakemisto saraketta kohti.

Toisaalta, jos taulukossa ei ole hakemistoindeksin sarakkeissa, se johtaa, kuten me kaikki tiedämme, huonoon suorituskykyyn SELECTsissa.

Indeksin tehokkuus riippuu myös joskus sarakkeen tyypistä; INT-sarakkeiden hakemistot näyttävät parhaan mahdollisen suorituskyvyn, mutta VARCHAR-, DATE- tai DECIMAL-indeksit (jos se on järkevää) eivät ole yhtä tehokkaita. Tämä huomio voi jopa johtaa taulukoiden uudelleensuunnitteluun, joita tulisi käyttää parhaalla mahdollisella tehokkuudella.

Siksi indeksointi on aina herkkä päätös, koska liikaa indeksointia voi olla yhtä vähän kuin liian vähän ja koska indeksoitavien sarakkeiden tietotyypillä on suuri vaikutus lopputulokseen.

Huono käytäntö # 8: Huono nimikkeistön käytäntö

Tätä ohjelmoijat kamppailevat aina, kun he kohtaavat olemassa olevan tietokannan: ymmärtävät, mitä tietoja siihen on tallennettu taulukoiden ja sarakkeiden nimillä, koska usein ei ole muuta tapaa.

Taulukon nimen tulisi kuvata, mitä kokonaisuutta se sisältää, ja jokaisen sarakkeen nimen tulisi kuvata, mitä tietoja se edustaa. Tämä on helppoa, mutta se alkaa hankalaksi, kun pöytien on liityttävä toisiinsa. Nimet alkavat sotkeutua ja pahentua, jos nimeämiskäytäntöjä sekoitetaan epäloogisiin sääntöihin (kuten esimerkiksi 'sarakkeen nimen on oltava korkeintaan 8 merkkiä'). Viimeinen seuraus on, että tietokannasta tulee lukukelvoton.

Siksi a nimeämiskäytäntö sitä tarvitaan aina, jos tietokannan odotetaan kestävän ja kehittyvän sen tukeman sovelluksen mukana, ja tässä on joitain ohjeita tiiviin, yksinkertaisen ja luettavan version luomiseksi:

• Ei rajoituksia taulukon tai sarakkeen nimelle. On parempi olla kuvaava nimi kuin lyhenne, jota kukaan ei muista tai ymmärrä.

• Samoilla nimillä on sama merkitys. Vältä kenttiä, joilla on sama nimi, mutta joilla on erilainen tyyppi tai merkitys; tämä on hämmentävää ennemmin tai myöhemmin.

• Ellei välttämätöntä, älä ole turha. Esimerkiksi 'Tuote' -taulukossa ei tarvitse olla sarakkeita, kuten 'Tuotteen nimi', 'Tuotteen hinta' tai vastaavia nimiä; 'Nimi' ja 'Hinta' ovat riittävät.

• Ole varovainen tietokannan moottorille varattujen sanojen suhteen. Jos sarakkeelle on annettava nimi 'Index', joka on SQL-varattu sana, yritä käyttää toista, kuten 'IndexNumber'.

• Jos pidät kiinni yksinkertaisen ensisijaisen avaimen (automaattisesti tuotettu yksittäinen kokonaisluku) -säännöstä, nimeä se jokaisessa taulukossa nimellä 'Id'.

• Jos liityt toiseen taulukkoon, määritä vaadittu vieras avain kokonaisluvuksi, jonka nimi on 'Id' ja liitetyn taulukon nimi (esim. IdItem).

• Jos rajoitukset on nimetty, käytä rajoitusta kuvaavaa etuliitettä (esimerkiksi 'PK' tai 'FK'), jota seuraa mukana olevan taulukon tai taulukoiden nimi. Tietysti alaviivojen ('_') säästäväinen käyttö tekee asioista luettavampia.

• Nimeä indeksit käyttämällä etuliitettä 'IDX', jota seuraa taulukon nimi ja hakemiston sarake tai sarakkeet. Käytä myös 'UNIQUE' etuliitteenä tai loppuliitteenä, jos hakemisto on yksilöllinen ja alleviivataan tarvittaessa.

Internetissä on monia tietokantojen nimeämisohjeita, jotka valaisevat tätä tietokannan suunnittelun erittäin tärkeää näkökohtaa, mutta näillä perusvaiheilla voit ainakin käyttää luettavaa tietokantaa. Tärkeää tässä ei ole nimitysohjeiden koko tai monimutkaisuus, vaan niiden johdonmukaisuus niiden noudattamisessa!

Jotkut loppuhavainnot

Tietokannan suunnittelu on yhdistelmä tietoa ja kokemusta; Ohjelmistoteollisuus on kehittynyt paljon sen perustamisesta lähtien. Onneksi käytettävissä on riittävästi tietoa tietokannan suunnittelijoille parhaan tuloksen saavuttamiseksi.

On hyviä suuntaviivat tietokantojen suunnittelussa kaikkialla Internetissä sekä huonoja tapoja Y välttämättömiä asioita tietokannan suunnittelussa. Valitse ja pidä kiinni.

Ja älä unohda, että vain kokeilemalla, tekemällä virheitä ja onnistumisia opit, joten mene eteenpäin ja aloita nyt.