Normaligo en la Reala Mondo
Normala normaligo estas unu el la sanktaj bovinoj de aplika evoluo. Ĉiu subprograma kurso, kiun vi prenis aŭ libron, kiun vi legis, verŝajne predikas la gravecon normalecigi datumbazojn .
Estas tempo por defii tiun truismon. Kelkfoje ĝi estas bone indiki vian datumbazon!
Kiam Devus Vi Normaligi?
Normala normaligo protektas la integrecon de via datumo. Ĝi estas bonega ideo en multaj kazoj, kaj vi devus komenci ajnan datumbazon dezajnon kun normaligo en menso. Se vi povas normaligi vian datumbazon, iru por ĝi! Fakte: Jen iu oportuna konsilo pri kiel normaligi vian datumaron en ĉi tiu retejo:
- Metante vian datumaron en Unua Normala Formo (1NF)
- Metante vian datumaron en Dua Normala Formo (2NF)
- Metante vian datumaron en Tria Normala Formo (2NF)
La fundo estas, ke vi devus normaligi vian datumbazon krom se vi havas tre bonan kialon por ne fari ĝin. Normaligado kutime estas sona praktika desegnado. Ĝi reduktas redundan informon, optimigas la agadon kaj reduktas la verŝajnecon, ke vi havos problemojn de integreco de datumoj, kiuj rezultas de havi la samajn datumojn starantajn en malsamaj anguloj de via datumbazo.
Iuj Bonaj Razoj Ne Normala
Dirite, ekzistas iuj bonaj kialoj por ne normala via datumbazo. Ni rigardu kelkajn:
- Junuloj estas multekostaj . Normala via datumbazo ofte implikas multajn tabulojn. Fakte, vi facile povas ekflugi kun tio, kion vi opinias, ke estas simpla konsulto, kiu ĉirkaŭprenas kvin aŭ 10 tabulojn. Se vi iam provis fari kvin-tablon kuniĝi, vi scias, ke ĝi funkcias en principo, sed ĝia malfacile malrapida praktiko. Se vi konstruas TTT-aplikaĵon, kiu dependas de multnombraj aliĝoj al grandaj tabloj, vi eble pensos, "Se nur ĉi tiu datumbazo ne estis normala!" Kiam vi aŭdos tion, kio pensis en via kapo, estas bone Konsideru nedormala. Se vi povas konservi ĉiujn datumojn de tiu konsulto en unu tablon sen vere kompromiti vian integrecon de datumoj, iru por ĝi! Esti ribelema kaj denormaligi vian datumbazon. Vi ne rigardos reen!
- Normala dezajno estas malfacila . Se vi laboras kun kompleksa datumbaza skemo , vi verŝajne trovos vin bangante vian kapon kontraŭ la tablo super la komplekseco de normaligo. Kiel simpla regulo de dikfingro, se vi pasigas la tutan tagon provante ekscii kiel moviĝi al la kvara normala formo, vi eble prenos normaligon tro malproksime. Revenu kaj demandu vin, se vere valoris daŭri.
- Rapida kaj malpura devus esti rapida kaj malpura . Se vi nur disvolvas prototipon, simple faru ĉion, kio funkcias rapide. Vere. Estas bone. Rapida aplika evoluo estas foje pli grava ol eleganta dezajno. Nur memoru reiri kaj zorgeme rigardu vian dezajnon kiam vi pretas movi preter la prototipo. La prezo, kiun vi pagas por rapida kaj malpura datumbazo, estas, ke vi eble devos forĵeti ĝin kaj ekflugi kiam estas tempo konstrui por produktado.
- Se vi uzas datumbazon de NoSQL , tradicia normaligo ne estas dezirinda. Anstataŭe, desegnu vian datumbazon per la modelo BASE, kiu estas multe pli pardonema. Ĉi tio estas utila kiam vi konservas nestrukturigitajn datumojn kiel retpoŝtojn, bildojn aŭ filmetojn.
Iuj Vortoj de Atento
Normala normaligo ĝenerale estas bona ideo. Vi devas provi sekvi la principojn de normaligo kiam ŝajnas esti racia fari tion. Sed se ĉiuj indikiloj indikas ke la normaligo estas tro kompleksa por efektivigi, konsideru alproksimiĝon, kiu faros la laborpostenon ankoraŭ protektante vian datumon.
Fine - se vi elektas forkuri de la reguloj de normaligo, estu eksterrigardema pri kiel vi devigas la integrecon de datumbazo. Se vi stokas redundan informon, metu ellasilon kaj aliajn kontrolojn en la loko por certigi, ke la informo subtenas konsekvenca.