Заједничке грешке направљене у дизајну базе података

Било да радите са базом података која садржи стотине записа или милионе записа, прави дизајн базе података је увек важан. Не само да ће олакшати проналажење информација, већ ће и поједноставити ширење базе података у будућности. Нажалост, лако је пасти у неколико замки које могу у будућности отежати ствари.

Постоје читаве књиге о предмету нормализације базе података, али ако једноставно избегнете ове уобичајене грешке, бићете на правом путу до доброг дизајна базе података.

Грешка базе података # 1: понављање поља у табели

Основно правило за добар дизајн базе података је препознавање понављајућих података и стављање тих понављајућих колона у своју столу. Понављање поља у табели је уобичајено за оне који су дошли из света табличних таблица, али док су таблице углавном равне према дизајну, базе података би требале бити релацијске. То је као да идете од 2Д до 3Д.

На срећу, понављана поља су обично лако препознати. Само погледајте ову табелу:

Шта се догађа када поруџбина садржи четири производа? Требали бисмо додати још једно поље на таблу како бисмо подржали више од три производа. И ако смо изградили клијентску апликацију око табле како би нам помогли да уносимо податке, можда ћемо морати да је изменимо новим производом. А како да нађемо све наруџбе са Јеллибеансом у реду? Бићемо приморани да упитамо свако поље производа у таблици са СКЛ изразом који може изгледати: СЕЛЕЦТ * ФРОМ Продуцтс ВХЕРЕ Продуцт1 = 'Јелли Беанс' ИЛИ ​​Продуцт2 = 'Јелли Беанс' ИЛИ ​​Продуцт3 = 'Јелли Беанс'.

Умјесто да имамо један сто који заједно садржи све информације, требали би имати три табеле које свако држи одређени дио информација. У овом примјеру желели би таблицу наруџбина са информацијама о самој наруџби, табели производа са свим нашим производима и ПродуцтОрдерс таблета која је повезала производе са поруџбином.

Обратите пажњу на то како свака табела има своје јединствено ИД поље. Ово је примарни кључ. Повезујемо табеле користећи вредност примарног кључа као инострани кључ у другој табели. Прочитајте више о примарним кључевима и страним кључевима.

Грешка базе података # 2: Уградња табеле у табели

Ово је још једна уобичајена грешка, али се не истиче увек исто колико и понављајућа поља. Када дизајнирате базу података, желите се уверити да се сви подаци у табели односе на саму себе. То је као дјечја игра о откривању онога што је другачије. Ако имате банану, јагоде, брескву и телевизор, телевизор вероватно припада негде другде.

Са истим редоследом, уколико имате таблицу продаваца, сви подаци из те табеле требају се посебно односити на ту особу продаје. Свака додатна информација која није јединствена за тој продајни особи може припадати негде другде у вашој бази података.

Иако ова табела може изгледати као да је све повезана са појединачним продавачем, она заправо има табелу уграђену у табелу. Обратите пажњу на то како Оффице и ОффицеНумбер понављају са "Аустин Довнтовн". Шта ако се телефонски број телефона промени? Требало би да ажурирате читав низ података за један појединачни део промене информација, што никада није добра ствар. Ова поља треба преселити на своју столу.

Овакав дизајн такође вам даје могућност додавања додатних информација у таблицу Оффицеа без стварања ноћне масе нереда у табели продајних особа. Замислите колико ће радити једноставно пратити улицну адресу, град, државу и поштански број ако су све те информације биле на столу за продају!

Грешка базе података # 3: стављање две или више информација у једно поље

Уношење података о канцеларији у табелу продајне особе није био једини проблем са тој бази података. Адреса за адресу садржи три информације: улицу, град и државу. Свако поље у бази података треба да садржи само један податак. Када имате више информација у једном пољу, може постати теже упитати базу података за информације.

На пример, шта ако желимо да покренемо упит о свим продајним људима из Аустина? Требало би да претражимо унутар поља за адресу, што није само неефикасно, већ може повратити лоше информације. На крају крајева, шта се дешава ако неко живи у Аустин улици у Портланду, Орегон?

Ево како би изгледао сто:

Ту је неколико ствари које треба приметити. Прво, "Аддресс1" и "Аддресс2" изгледа да пада под грешку понављања поља.

Међутим, у овом случају они се односе на одвојене дијелове података који се односе директно на продајно лице, а не на понављајућу групу података који би требали ићи у своју столу.

Такође, као бонус грешку која се избегава, приметићете како је форматирање броја телефона уклоњено из табеле. Требало би избјећи чување формата поља када је уопће могуће. У случају телефонских бројева, постоји више начина на који људи упишу број телефона: 215-555-5858 или (215) 555-5858. То би учинило потрагу за продајном особом по броју телефона или претраживањем продаваца у истом подручју на подручју.

Грешка базе података # 4: не користи тачан примарни кључ

У већини случајева, желите применити аутоматски повећавајући број или неки други генерисани број или алфанумерички за примарни кључ. Треба избјећи кориштење било каквих стварних информација за примарни кључ, чак и ако звучи као да би направио добар идентификатор.

На пример, ми свако има свој индивидуални број социјалног осигурања, тако да коришћење броја социјалног осигурања за базу података запослених може изгледати као добра идеја. Али, иако ретко, могуће је да се чак и број социјалног осигурања промени, и никада не желимо да се наш примарни кључ промени.

И то је проблем при коришћењу стварних информација као кључне вредности. Може се променити.

Грешка базе података # 5: Не користи конвенцију именовања

Ово можда не звучи као велика ствар када први пут започнете дизајнирање ваше базе података, али када једном дођете до тачке уписивања упита на базу података да бисте преузели информације, имање конвенције за именовање ће вам помоћи приликом запамтења имена поља.

Само замислите колико је тежи тај процес ако би се имена чувала као ФирстНаме, ЛастНаме у једној табели и фирст_наме, ласт_наме у другој табели.

Две најпопуларније конвенције о именовању капитализују прво слово сваке речи на пољу или раздвајају речи помоћу подвучице. Можете видети и неке програмере који капитализују прво слово сваке речи, осим прве речи: фирстНаме, ластНаме.

Такође ћете желети да одлучите о коришћењу имена сингуларних таблица или имена плуралних таблица. Да ли је то табел за поруџбину или табела наруџбине? Да ли је стол за клијенте или таблице купаца? Опет, не желите да се заглавите са таблицом за поруџбину и таблицима за купце.

Конвенција о имену која сте изабрала није толико важна као процес стварног избора и придржавања конвенције о именовању.

Грешка базе података # 6: Неправилно индексирање

Индексирање је једна од најтежих ствари које су у праву, посебно за оне нове у дизајну базе података. Сви примарни кључеви и инострани кључеви требају бити индексирани. То је оно што повезује табеле заједно, тако да без индекса, видећете врло лоше перформансе из ваше базе података.

Али оно што је често недостаје су друга поља. То су поља "ВХЕРЕ". Ако често ћете смањити претрагу помоћу поља у ВХЕРЕ клаузули, желите размислити о стављању индекса у то поље. Међутим, не желите превише индексирати табелу, што може и да повреди перформансе.

Како одлучити? Ово је део уметности дизајна базе података. Не постоје тешке границе колико индекса треба ставити на стол. Пре свега, желите индексирати било које поље које се често користи у ВХЕРЕ клаузули. Прочитајте више о правилном индексирању ваше базе података.