Нормализација у стварном свету
Нормализација базе података је једна од светих крава развоја апликација. Сваки додипломски програм који сте водили или сте прочитали вјероватно пропагира важност нормализације база података .
Време је да се оспори тај труизам. Понекад је у реду да деформирате своју базу података!
Када бисте требали нормализовати?
Нормализација базе података штити интегритет ваших података. То је сјајна идеја у многим случајевима, и требали бисте започети било који подухват дизајна базе података с нормализацијом у виду. Ако можете нормализовати своју базу података, идите по њега! У ствари, Ево неких практичних савета о томе како нормализовати своју базу података на овој локацији:
- Постављање ваше базе података у прву нормалну форму (1НФ)
- Постављање ваше базе података у другу нормалну форму (2НФ)
- Постављање ваше базе података у трећу нормалну форму (2НФ)
Доња линија је да требате нормализирати своју базу података, осим ако имате стварно добар разлог да то не учините. Нормално је обично звучна пракса дизајна. Смањује се редундантне информације, оптимизује перформансе и смањује вероватноћу да ћете имати проблема са интегритетом података који резултирају тиме што су исте податке срушене у различитим угловима ваше базе података.
Неки добри разлози нису нормализовани
Ипак, постоје неки добри разлози да се ваша база података не нормализује. Погледајмо неколико:
- Придруживање је скупо . Нормирање ваше базе података често подразумева стварање пуно табела. У ствари, лако можете да завршите са оним што мислите да би требало да буде једноставан упит који обухвата пет или 10 табела. Ако сте икада покушали да учествујете у пет столова, знате да то функционише у принципу, али да је у пракси тешко споро. Ако креирате веб апликацију која се ослања на питања вишеструких удруживања против великих табела, можда ћете знати да размишљате: "Ако само ова база података није нормирана!" Када чујете ту мисао у глави, добро је вријеме размотрите денормализацију. Ако можете да задржите све податке које је тај упит користио у једној табели без стварног угрожавања интегритета ваших података, идите по њега! Будите побуњеник и денормализујте своју базу података. Нећете се вратити!
- Нормализовани дизајн је тежак . Ако радите са сложеном шемом базе података , вероватно ћете наћи ударање главе против стола због сложености нормализације. Као једноставно правило, ако проводите цео дан покушавајући да схватите како да пређете на четврту нормалну форму, можда ћете предузимати нормализацију. Одмакните се и питајте се да ли је стварно вредно наставити.
- Брзо и прљаво треба брзо и прљаво . Ако само развијате прототип, урадите све што брзо ради. Стварно. У реду је. Брзи развој апликација понекад је важнији од елегантног дизајна. Само запамтите да се вратите назад и пажљиво погледајте на свој дизајн када сте спремни да пређете корак даље од фазе израде прототипа. Цена коју плаћате за брзу и прљаву дизајн базе података јесте да ћете можда морати да га избаците и почнете када је време да се производите за производњу.
- Ако користите НоСКЛ базу података , традиционална нормализација није пожељна. Уместо тога, дизајнирајте своју базу користећи БАСЕ модел који је далеко више опраштајући. Ово је корисно када чувате неструктуиране податке као што су е-поште, слике или видео записи.
Неке речи опреза
Нормирање базе података је, уопштено, добра идеја. Требали бисте покушати да пратите принципе нормализације када је то разумно. Али ако сви индикатори указују на нормализацију који је сувише сложен да би се имплементирао, размотрите приступ који ће обавити посао док још увек штити ваше податке.
Коначно - ако одлучите да одустанете од правила нормализације, будите пажљиви у погледу начина на који провјерите интегритет базе података. Ако чувате редундантне информације, ставите активирање и друге контроле како бисте били сигурни да информације остану доследне.