Yn ôfwachting fan it begjin fan de folgjende stream op it taryf Wy hawwe in lyts auteursmateriaal taret mei wichtige tips foar it ûntwerpen fan in database. Wy hoopje dat dit materiaal nuttich foar jo sil wêze.
Databanken binne oeral: fan 'e ienfâldichste blogs en mappen oant betroubere ynformaasjesystemen en grutte sosjale netwurken. Oft de databank ienfâldich of kompleks is, is net sa wichtich as it wichtich is om it goed te ûntwerpen. As in databank sûnder tinken en sûnder in dúdlik begryp fan it doel is ûntwurpen, is it net allinich net effektyf, mar fierder wurkjen mei de databank sil in echte pine wêze, in ûntrochsichtich bosk foar brûkers. Hjir binne wat tips foar database-ûntwerp dy't jo sille helpe om in nuttich en maklik te brûken produkt te meitsjen.
1. Bepale wêr't de tafel foar is en wat de struktuer is
Tsjintwurdich helpe ûntwikkelingsmetoaden lykas Scrum of RAD (Rapid Application Development) IT-teams by it ûntwikkeljen fan databases fluch. Lykwols, yn 'e efterfolging fan' e tiid is de ferlieding heul grut om direkt te dûken yn it bouwen fan in basis, vague foarstelle wat it doel sels is, wat de definitive resultaten moatte wêze.
It is as is it team rjochte op effisjint, fluch wurk, mar dit is in mirage. Hoe fierder en flugger jo dûke yn 'e djipte fan it projekt, hoe mear tiid it sil nimme om flaters te identifisearjen en te feroarjen yn it databankûntwerp.
Dat it earste ding dat jo moatte beslute is om it doel foar jo database te definiearjen. Foar hokker type applikaasje wurdt de databank ûntwikkele? Sil de brûker allinnich wurkje mei records en moatte betelje omtinken oan transaksjes, of is er mear ynteressearre yn gegevens analytics? Wêr moat de basis ynset wurde? Sil it klantgedrach folgje of gewoan klantrelaasjes beheare?
Hoe earder it ûntwerpteam dizze fragen beantwurdet, hoe soepeler it proses fan it databankûntwerp sil wêze.
2. Hokker gegevens moat ik kieze foar opslach?
Foarútplanne. Gedachten oer wat de side of systeem wêrfoar de databank wurdt ûntwurpen sil dwaan yn 'e takomst. It is wichtich om fierder te gean as de ienfâldige easken fan 'e technyske spesifikaasjes. Begjin asjebleaft net te tinken oer alle mooglike soarten gegevens dy't in brûker ea sil opslaan. Tink ynstee dêrfan oer oft brûkers berjochten kinne skriuwe, dokuminten of foto's uploade, of berjochten útwikselje kinne. As dit it gefal is, dan moatte jo romte foar har tawize yn 'e databank.
Wurkje mei it team, ôfdieling of organisaasje wêrfoar de ûntwerpbasis yn 'e takomst sil wurde stipe. Kommunisearje mei minsken op ferskate nivo's, fan klanttsjinstspesjalisten oant ôfdielingshaden. Op dizze manier, mei help fan feedback, krije jo in dúdlik idee fan 'e easken fan it bedriuw.
Unferjitlik sille de behoeften fan brûkers binnen sels deselde ôfdieling konflikt wêze. As jo dit tsjinkomme, wês dan net bang om op jo eigen ûnderfining te fertrouwen en in kompromis te finen dat past by alle partijen en foldocht oan it úteinlike doel fan 'e databank. Wês der wis fan: yn 'e takomst krije jo +100500 yn karma en in berch koekjes.
3. Model gegevens mei soarch
D'r binne ferskate wichtige punten om omtinken te jaan by it modellearjen fan gegevens. Lykas wy earder sein hawwe, bepaalt it doel fan 'e databank hokker metoaden moatte wurde brûkt yn modellering. As wy in databank ûntwerpe foar online rekordferwurking (OLTP), mei oare wurden foar it meitsjen, bewurkjen en wiskjen fan records, brûke wy transaksjemodellen. As de databank relasjoneel wêze moat, dan is it it bêste om multydimensionale modellering te brûken.
Tidens modellering wurde konseptuele (CDM), fysike (PDM), en logyske (LDM) gegevensmodellen boud.
Konseptuele modellen beskriuwe entiteiten en de soarten gegevens dy't se befetsje, lykas de relaasjes tusken har. Diel jo gegevens yn logyske brokken - it makket it libben folle makliker.
It wichtichste ding is moderaasje, oerdriuw it net.
As in entiteit tige lestich is om te klassifisearjen yn ien wurd of frase, dan is it tiid om subtypen (berne-entiteiten) te brûken.
As in entiteit har eigen libben liedt, hat attributen dy't har gedrach en har uterlik beskriuwe, lykas relaasjes mei oare objekten, dan kinne jo feilich net allinich in subtype brûke, mar ek in supertype (âldere entiteit).
As jo dizze regel negearje, sille oare ûntwikkelders betize wurde yn jo model en sille de gegevens en de regels net folslein begripe foar hoe't se se sammelje.
Konseptuele modellen wurde ymplementearre mei logyske modellen. Dizze modellen binne as in roadmap foar fysyk databankûntwerp. Yn it logyske model wurde saaklike gegevens entiteiten identifisearre, gegevenstypen wurde bepaald, en de status fan 'e regelkaai wurdt bepaald dy't de relaasjes tusken gegevens regelje.
Dan wurdt it logyske gegevensmodel fergelike mei it foarselekteare DBMS (databasebehearsysteem) platfoarm en wurdt in fysyk model krigen. It beskriuwt hoe't gegevens fysyk opslein wurde.
4. Brûk de juste gegevenstypen
It brûken fan it ferkearde gegevenstype kin resultearje yn minder krekte gegevens, swierrichheden by it oanmeitsjen fan tabellen, muoite mei syngronisearjen fan attributen en opblaasde triemgrutte.
Om de yntegriteit fan ynformaasje te garandearjen, moat in attribút allinich gegevenstypen befetsje dy't der foar akseptabel binne. As leeftyd wurdt ynfierd yn de databank, soargje derfoar dat de kolom bewarret hiele getallen fan maksimaal 3 sifers.
Meitsje in minimum fan lege kolommen mei in NULL wearde. As jo alle kolommen as NULL oanmeitsje, is dit in grutte flater. As jo in lege kolom nedich hawwe om in spesifike saaklike funksje út te fieren, as de gegevens ûnbekend binne of noch net sin meitsje, fiel jo dan frij om it te meitsjen. Ommers, wy kinne net ynfolje de kolommen "Datum fan ferstjerren" of "Datum fan ûntslach" foarôf;
De measte modellearingssoftware (ER/Studio, MySQL Workbench, SQL DBM, gliffy.com) gegevens kinne jo prototypen meitsje fan gegevensregio's. Dit soarget net allinich foar it juste gegevenstype, applikaasjelogika en goede prestaasjes, mar ek dat de wearde fereaske is.
5. Gean natuerlik
As jo beslute hokker kolom yn in tabel te brûken as kaai, beskôgje altyd hokker fjilden de brûker kin bewurkje. Nea kieze se as in kaai - in min idee. Alles kin barre, mar jo moatte derfoar soargje dat it unyk is.
It is it bêste om in natuerlike, as saaklike, kaai te brûken. It hat in semantyske betsjutting, dus jo sille duplikaasje yn 'e databank foarkomme.
Behalven as de saaklike kaai unyk is (foarnamme, efternamme, posysje) en wurdt werhelle yn ferskate rigen fan 'e tabel of it moat feroarje, dan moat de generearre keunstmjittige kaai wurde oanwiisd as de primêre kaai.
6. Normalisearje yn moderaasje
Om gegevens effektyf te organisearjen yn in databank, moatte jo in set fan rjochtlinen folgje en de databank normalisearje. Der binne fiif normale foarmen te folgjen.
Mei normalisaasje foarkomme jo oerstalligens en soargje jo foar de yntegriteit fan 'e gegevens brûkt yn jo applikaasje of side.
Lykas altyd moat alles yn moderaasje wêze, sels normalisearring. As d'r tefolle tabellen yn 'e databank binne mei deselde unike kaaien, dan binne jo de databank fuorthelle en oernormalisearre. Oermjittige normalisaasje beynfloedet de prestaasjes fan de database negatyf.
7. Test betiid, test faak
Testplan en juste testen moatte diel útmeitsje fan database-ûntwerp.
De bêste manier om jo databank te testen is troch trochgeande yntegraasje. Simulearje in "dei yn it libben fan in databank" senario en kontrolearje oft alle rânegefallen wurde behannele en hokker brûkersynteraksjes wierskynlik binne. Hoe earder jo bugs fine, hoe mear jo tiid en jild sille besparje.
Dit binne mar sân tips dy't jo kinne brûke om in geweldige databank foar produktiviteit en effisjinsje te ûntwerpen. As jo se folgje, sille jo de measte hoofdpijn yn 'e takomst foarkomme. Dizze tips binne gewoan it tip fan 'e iisberch yn databankmodellering. D'r binne in grut oantal life hacks. Hokker brûke jo?
Boarne: www.habr.com