Без разлика дали работите со база на податоци што содржат стотици записи или милиони записи, правилен дизајн на бази на податоци е секогаш важен. Не само што ќе го олесни пребарувањето на информациите, туку и ќе ја поедностави проширувањето на базата на податоци во иднина. За жал, лесно е да паднеме во неколку замки што може да ги отежнат работите во иднина.
Постојат цели книги напишани на тема нормализирање на базата на податоци, но ако едноставно ги избегнувате овие вообичаени грешки, ќе бидете на вистинскиот пат до добар дизајн на базата.
Грешка во базата на податоци # 1: Повторувачки полиња во табела
Основно правило за добар дизајн на бази на податоци е да ги препознае повторените податоци и да ги става тие повторувачки колони во сопствената табела. Повторувачките полиња во табелата се вообичаени за оние кои доаѓаат од светот на табеларни пресметки, но додека табеларните таблички имаат тенденција да бидат рамни според дизајнот, базите на податоци треба да бидат релациони. Тоа е како да оди од 2D во 3D.
За среќа, повторливи полиња обично се лесно да се забележат. Само погледнете ја оваа табела:
| OrderID | Product1 | Product2 | Производ3 |
| 1 | Мечиња | Желе Грав | |
| 2 | Желе Грав |
Што се случува кога нарачката содржи четири производи? Ние ќе треба да додадеме друго поле на табелата за поддршка на повеќе од три производи. И ако изградивме клиентска апликација низ табелата за да ни помогнеме да внесуваме податоци, можеби ќе треба да ја измениме со ново поле за производот. И како да ги најдеме сите нарачки со Jellybeans во ред? Ние ќе бидеме принудени да го побараме секое поле за производот во табелата со изјава на SQL која би можела да изгледа: Избери * Од производите КАДЕ Производ1 = 'Желе зрна' ИЛИ Производ2 = 'Желе зрна' ИЛИ Производ3 = 'Желе зрнца'.
Наместо да имаме единствена маса која ги содржи сите информации заедно, треба да имаме три табели кои секој од нив имаат посебен дел од информациите. Во овој пример, ние би сакале табела на нарачки со информации за самата нарачка, табела Производи со сите наши производи и таблет ProductOrders кои ги поврзаа производите со цел.
| OrderID | CustomerID | Датум на нарачка | Вкупно |
| 1 | 7 | 1/24/17 | 19.99 |
| 2 | 9 | 1/25/17 | 24.99 |
| ProductID | Производ | Грофот |
| 1 | Мечиња | 1 |
| 2 | Желе Грав | 100 |
| ProductOrderID | ProductID | OrderID |
| 101 | 1 | 1 |
| 102 | 2 | 1 |
Забележете како секоја табела има свое сопствено уникатно поле за идентификација. Ова е примарен клуч. Ние ги поврзуваме табелите со користење на примарниот клуч како странски клуч во друга табела. Прочитајте повеќе за примарни клучеви и странски клучеви.
Грешка во базата на податоци # 2: Внесување табела во табела
Ова е уште една вообичаена грешка, но тоа не секогаш издвојува толку многу како повторувачки полиња. Кога дизајнирате база на податоци, сакате да бидете сигурни дека сите податоци во табелата се поврзани со себе. Тоа е како игра на детето за да забележиш што е различно. Ако имате банана, јагода, праска и телевизор, телевизорот веројатно припаѓа некаде на друго место.
Заедно со истата линија, ако имате табела за продажни луѓе, сите информации во таа табела треба да се однесуваат конкретно за тоа лице за продажба. Секоја дополнителна информација која не е единствена за тоа лице за продажба може да припаѓа некаде на друго место во вашата база на податоци.
| SalesID | Прво | Последно | Адреса | Телефонски број | Канцеларија | OfficeNumber |
| 1 | Сем | Елиот | 118 Main St, Остин, Тексас | (215) 555-5858 | Остин центарот | (212) 421-2412 |
| 2 | Алис | Смит | 504 2nd Street, Њујорк, Њујорк | (211) 122-1821 | Њујорк (Исток) | (211) 855-4541 |
| 3 | Џо | Парохија | 428 Aker, Остин, Тексас | (215) 545-5545 | Остин центарот | (212) 421-2412 |
Додека оваа табела може да изгледа како да е поврзана со индивидуалниот продавач, всушност има табела вметната во табелата. Забележете како Office и OfficeNumber се повторуваат со "Остин центарот". Што ако се промени телефонскиот број на канцеларијата? Ќе треба да обновите цела низа на податоци за едно парче промена на информации, што никогаш не е добра работа. Овие полиња треба да се пренесат на сопствената табела.
| SalesID | Прво | Последно | Адреса | Телефонски број | OfficeID |
| 1 | Сем | Елиот | 118 Main St, Остин, Тексас | (215) 555-5858 | 1 |
| 2 | Алис | Смит | 504 2nd Street, Њујорк, Њујорк | (211) 122-1821 | 2 |
| 3 | Џо | Парохија | 428 Aker, Остин, Тексас | (215) 545-5545 | 1 |
| OfficeID | Канцеларија | OfficeNumber |
| 1 | Остин центарот | (212) 421-2412 |
| 2 | Њујорк (Исток) | (211) 855-4541 |
Овој тип на дизајн, исто така, ви дава можност да додадете дополнителни информации во табелата на Office без создавање на кошмар на неред во табелата за продажби. Замислете колку ќе работи работата за едноставно следење на уличната адреса, градот, државата и поштенскиот код, ако целата таа информација е во табелата за продажба!
Грешка во базата на податоци # 3: Ставање на две или повеќе делови на информации во едно поле
Вметнувањето на канцелариските информации во табелата за продажба не беше единствениот проблем со таа база на податоци. Полето за адреса содржи три информации: улица, град и држава. Секое поле во базата на податоци треба да содржи само едно парче информација. Кога имате повеќе информации во едно поле, може да биде потешко да ја пребарувате базата на податоци за информации.
На пример, што ако сакаме да извршиме барање за сите продажни луѓе од Остин? Треба да пребаруваме во полето за адреса, што не е само неефикасно, туку може да врати лоши информации. Впрочем, што се случува ако некој живеел на улица Остин во Портланд, Орегон?
Еве што треба да изгледа табелата:
| SalesID | Прво | Последно | Адреса 1 | Адреса 2 | Град | Држава | Zip | Телефон |
| 1 | Сем | Елиот | 118 Main St | Остин | TX | 78720 | 2155555858 | |
| 2 | Алис | Смит | 504 2-ри ул | Њујорк | NY | 10022 | 2111221821 | |
| 3 | Џо | Парохија | Ул "Акер" № 428 | Apt 304 | Остин | TX | 78716 | 2155455545 |
Постојат неколку работи кои треба да ги забележите овде. Прво, "Address1" и "Address2" се чини дека спаѓаат под повторувачката грешка.
Меѓутоа, во овој случај тие се однесуваат на одделни делови од податоци кои се однесуваат директно на продавачот, а не на повторувачка група на податоци што треба да одат во сопствената табела.
Исто така, како бонус грешка за да се избегне, забележете како форматирањето за телефонскиот број е одземено од табелата. Треба да избегнете складирање на форматот на полиња кога е можно. Во случај на телефонски броеви, постојат неколку начини на кои луѓето пишуваат телефонски број: 215-555-5858 или (215) 555-5858. Ова би го олеснило пребарувањето на продажбата на лице по телефонски број или на барање на продажни лица во истиот област код потешко.
Грешка во базата на податоци # 4: Не се користи правилен примарен клуч
Во повеќето случаи, ќе сакате да користите автоматски растечки број или друг генериран број или алфанумерички за вашиот примарен клуч. Треба да избегнувате да користите какви било вистински информации за примарниот клуч, дури и ако звучи како да направи добар идентификатор.
На пример, секој од нас има свој индивидуален број за социјално осигурување, така што користењето на бројот на социјалното осигурување за базата на податоци на вработените може да звучи како добра идеја. Но, иако ретко, можно е дури и број за социјално осигурување да се промени, а ние никогаш не сакаме да го смениме нашиот примарен клуч.
И тоа е проблемот со користење на вистинските информации како клучна вредност. Тоа може да се промени.
Грешка во базата на податоци # 5: Не користи Конвенција за именување
Ова можеби не звучи како голема работа кога за прв пат ќе започнете да ја дизајнирате вашата база на податоци, но откако ќе стигнете до точка на пишување на барањето за базата на податоци за да добиете информации, имајќи конвенција за именување ќе ви помогне додека ги меморирате имињата на полињата.
Замислете колку е потешко тој процес да биде ако имињата се зачувани како FirstName, LastName во една табела и first_name, last_name во друга табела.
Двете најпопуларни конвенции за именување ја капитализираат првата буква од секој збор во полето или ги одвојуваат зборовите со користење на потцрв. Вие исто така може да видите некои програмери да ја капитализираат првата буква од секој збор, освен првиот збор: firstName, lastName.
Исто така, ќе сакате да одлучувате за користење на имиња на единствени табели или имиња на множествени табели. Дали е табела со цел или табела на нарачки? Дали е табела на купувачи или табела на клиенти? Повторно, не сакате да бидете заглавени со Табела за Ред и Табела на клиенти.
Конвенцијата за именување која ја избирате не е толку важна како што е процесот на всушност избор и држење кон конвенција за именување.
Грешка во базата на податоци # 6: Неправилно индексирање
Индексирањето е една од најтешките работи што треба да се исправи, особено за оние кои се нови при дизајнирање на бази на податоци. Сите примарни клучеви и странски клучеви треба да се индексираат. Тоа е она што поврзува табели заедно, па без индекс, ќе видите многу лоши перформанси надвор од вашата база на податоци.
Но, она што премногу често се пропушта е другите полиња. Ова се полето "WHERE". Доколку често го ограничувате пребарувањето со користење на поле во клаузула WHERE, сакате да размислите за ставање индекс во тоа поле. Сепак, не сакате премногу да ја индексирате табелата, што исто така може да му наштети на перформансите.
Како да се одлучи? Ова е дел од уметноста на дизајнот на бази на податоци. Нема цврсти граници за тоа колку индекси треба да ги ставите на маса. Првенствено, сакате да индексирате кое било поле кое често се користи во клаузулата WHERE. Прочитајте повеќе за правилно индексирање на вашата база на податоци.