Normalisearring yn 'e Real World
Databanknarisearring is ien fan 'e hillige kij fan' e oanfalsûntwikkeling. Elk ûndergrûnske programma-kursus dy't jo nommen hawwe of jo boek hawwe jo wierskynlik it preekjen fan it betsjutting fan normearjende databanken .
It is tiid om it truïsis te reitsjen. Somtiden is it goed om jo databank te minimalisearjen!
Wannear moatte jo normearje?
Databanknormalisaasje beskermet jo yntegriteit fan jo gegevens. It is in geweldige idee yn in protte gefallen, en jo moatte alle databestânskema begjinne mei it normalisearjen yn 'tens. As jo jo databank normalisearje kinne, gean dan foar! In feit, hjir is wat praktysk advys oer hoe't jo jo databank opnarisearje op dizze side:
- Stel jo database yn First Normal Form (1NF)
- Soargen jo databank yn twadde normale foarmen (2NF)
- Stel jo database yn tredde normale foarmen (2NF)
De ûnderste rigel is dat jo jo databank normalisearje moatte, útsein jo hawwe in echt goede reden net te dwaan. Normalisearjen is normaal lûd-ûntwerppraktyk. It rediget redundante ynformaasje, optimearret de prestaasje en fergruttet de wikseling dat jo gegevens yntegriteitfragen hawwe dy't resultaat wurde fan itselde gegevens dat jo yn ferskillende hoeken fan jo database hawwe.
Guon goeie redenen net te normalisearjen
Dat sei, der binne guon redenen net om jo databank te normalisearjen. Litte wy nei in pear sjogge:
- Joielen binne djoer . It normearjen fan jo databank befetsje faak in protte tafels. Yn feite kinne jo gewoan opwekke mei wat jo tinke moatte in ienfâldich fraach wêze dy't fent of 10 tabellen spand. As jo altyd besocht hawwe mei in fiif-tabel mei te dwaan, wite jo dat it yn prinsipe wurket, mar har pynlike trageazens yn 'e praktyk. As jo in webapplikaasje oanmeitsje dy't op meardere oanfreegjen fan fragen stipet, kinne jo sels tinke, "As jo dizze databank net normalisearre binne!" As jo dat gedachte yn 'e holle hearre, it is in goede tiid om beskôgje de demormalisearing. As jo alle gebrûk fan dat gegevens brûke kinne yn in single tabel sûnder dat jo gegevens yntegriteit te gefolch binne, gean dan foar! Wês in rebel en jouwe jo databank. Jo sjogge net werom!
- Normalisearre ûntwerp is dreech . As jo wurkje mei in komplekse databest skema , sille jo wierskynlik jo sels de kop tsjin 'e tafel klimme oer de kompleetiteit fan normalisearring. As ienfâldige regel fan thumb, as jo de hiele dei besykje te besykjen om út te finen hoe't jo nei de fjirde normale foarm ferpleatse, kinne jo faaks normaasje nimme. Stap werom en freegje jo sels as it echt wurdich bliuwt.
- Fluch en dreech moatte fluch en smoarch wêze . As jo krekt in prototype ûntwikkele binne, dogge allinich wat fluch. Werklik. It is ok. Rapid applikaasjeûntwikkeling is somtiden wichtiger as elegant design. Tink derom om werom te gean en in soarchfâldich each op jo ûntwerp te nimmen as jo ree binne om fierder te gean nei de prototypefaze. De priis dy't jo betelje foar in flugge en drege database ûntwerp is dat jo miskien moatte om fuort te bringen en te begjinnen as it tiid is foar produksje te bouwen.
- As jo in NoSQL-database brûke , is tradisjonele normaasje net winsklik. Kontrolearje jo database mei it BASE- model dat fierder ferjouwing is. Dit is handich as jo ûnstruktuerde data bewarje lykas e-posten, ôfbyldings of fideos.
Guon Words of Caution
Databanknarisearring is algemien in goed idee. Jo moatte besykje de prinsipes fan normalisaasje folgje te litten as it liket te rjochtsjen te dwaan. Mar as alle yndikanten ferwize nei normalisearring te foldwaan om te realisearjen, beskôgje in oanpak dy't de opdracht krije sil as jo jo gegevens beskermje.
As lêste - as jo kieze om fan 'e regels fan normalisaasje te ferslaan, wurde ekstra wachrang oer hoe't jo de yntegriteit fan de database brûke. As jo redundante ynformaasje opslaan, sette triggers en oare kontrôles yn plak om derfoar te soargjen dat ynformaasje ynformaasje konsekwint.