Normalisering in die regte wêreld
Databasis normalisering is een van die heilige koeie van toepassingsontwikkeling. Elke voorgraadse programmeringskursus wat jy geneem of bespreek het, lees jy waarskynlik die belangrikheid van die normalisering van databasisse .
Dit is tyd om daardie truïsme uit te daag. Soms is dit reg om jou databasis te deformaliseer!
Wanneer moet jy normaliseer?
Databasis normalisering beskerm die integriteit van jou data. Dit is 'n goeie idee in baie gevalle, en jy moet begin met 'n databasisontwerppoging met normalisering in gedagte. As jy jou databasis kan normaliseer, gaan dit! Trouens, hier is 'n paar praktiese raad oor hoe om jou databasis op hierdie webwerf te normaliseer:
- Plaas jou databasis in eerste normale vorm (1NF)
- Plaas jou databasis in tweede normale vorm (2NF)
- Plaas jou databasis in Derde Normale Vorm (2NF)
Die bottom line is dat jy jou databasis moet normaliseer tensy jy 'n baie goeie rede het om dit nie te doen nie. Normalisering is gewoonlik 'n goeie ontwerppraktyk. Dit verminder oortollige inligting, optimaliseer prestasie en verminder die waarskynlikheid dat u data-integriteitskwessies sal hê wat die gevolg is van dieselfde data in verskillende hoeke van u databasis.
Sommige goeie redes om nie te normaliseer nie
Daar word gesê dat daar goeie redes is om nie jou databasis te normaliseer nie. Kom ons kyk na 'n paar:
- Sluitings is duur . Normalisering van jou databasis behels dikwels die skep van baie tafels. Trouens, jy kan maklik opkom met wat jy dink 'n eenvoudige navraag moet wees wat vyf of 10 tafels oorskry. As jy ooit probeer het om 'n vyftafelbyeenkoms te doen, weet jy dat dit in beginsel werk, maar dit is mettertyd stadig in die praktyk. As jy 'n webtoepassing bou wat afhanklik is van verskeie navrae met groot tafels, kan jy dalk dink: "As hierdie databasis nie genormaliseer is nie!" As jy daardie gedagte in jou kop hoor, is dit 'n goeie tyd om oorweeg denormalisering. As jy al die data wat deur die navraag gebruik word, in 'n tafel kan stoor sonder om jou data-integriteit regtig in gevaar te bring, gaan dit! Wees 'n rebel en ontwoor jou databasis. Jy sal nie terugkyk nie!
- Normale ontwerp is moeilik . As u met 'n komplekse databasisskema werk, sal u waarskynlik u kop teen die tafel slaan oor die kompleksiteit van normalisering. As 'n duidelike reël, as jy die hele dag bestee om te probeer uitvind hoe om na die vierde normale vorm te beweeg, kan jy dalk te normalisering neem. Stap terug en vra jouself of dit regtig die moeite werd is om voort te gaan.
- Vinnig en vuil moet vinnig en vuil wees . As jy net 'n prototipe ontwikkel, doen net wat werk vinnig. Regtig. Dit is OK. Vinnige aansoekontwikkeling is soms belangriker as elegante ontwerp. Onthou net om terug te gaan en jou ontwerp noukeurig te kyk sodra jy gereed is om verder as die prototiperingsfase te beweeg. Die prys wat jy betaal vir 'n vinnige en vuil databasisontwerp, is dat jy dit dalk nodig kan hê om dit weg te gooi en te begin wanneer dit tyd is om vir produksie te bou.
- As u 'n NoSQL-databasis gebruik , is tradisionele normalisering nie wenslik nie. In plaas daarvan, ontwerp jou databasis met behulp van die BASE- model wat baie vergewensgesind is. Dit is handig as u ongestruktureerde data stoor, soos e-posse, beelde of video's.
Sommige woorde van versigtigheid
Databasis normalisering is oor die algemeen 'n goeie idee. U moet probeer om die beginsels van normalisering te volg wanneer dit redelik lyk om dit te doen. Maar as alle aanwysers daarop dui dat normalisering te ingewikkeld is om te implementeer, beskou 'n benadering wat die werk sal verrig terwyl jy steeds jou data beskerm.
Ten slotte - as jy kies om af te wyk van die reëls van normalisering, wees ekstra waaksaam oor hoe jy databasisintegriteit afdwing. As jy oortollige inligting stoor, stel snellers en ander kontroles in plek om seker te maak dat die inligting konsekwent bly.