Независимо дали работите с база данни, съдържаща стотици записи или милиони записи, правилният дизайн на база данни винаги е важен. Не само ще направи много по-лесно извличането на информацията, но и ще опрости разширяването на базата данни в бъдеще. За съжаление, лесно е да попаднете на няколко капана, които могат да направят нещата трудни в бъдеще.
Има цели книги, които са написани по въпроса за нормализирането на база данни, но ако просто избягвате тези често срещани грешки, вие ще сте на прав път за добрия дизайн на базата данни.
Грешка в базата данни # 1: Повтарящи се полета в таблица
Основно правило за добър дизайн на базата данни е да разпознават повтарящите се данни и да поставят тези повтарящи се колони в собствената си таблица. Повтарящите се полета в таблицата са общи за тези, които са дошли от света на електронните таблици, но докато електронните таблици са склонни да бъдат плоски по дизайн, базите данни трябва да са релационни. Това е като да отидете от 2D към 3D.
За щастие, повтарящите се полета обикновено са лесно забележими. Просто погледнете тази маса:
| OrderID | Продукт 1 | PRODUCT2 | Product3 |
| 1 | Плюшени мечета | Желирани бонбони | |
| 2 | Желирани бонбони |
Какво се случва, когато поръчката съдържа четири продукта? Трябва да добавим още едно поле в таблицата, за да подкрепим повече от три продукта. И ако сме изградили клиентска програма около масата, за да ни помогнете да вмъкнем данни, може да се наложи да я променим с новото поле на продукта. И как да намерим всички нареждания с Jellybeans в реда? Ще бъдем принудени да запитваме всяко поле на продукта в таблицата с SQL израз, който може да изглежда като: SELECT * FROM Продукти WHERE Product1 = 'Желен фасул' ИЛИ Product2 = 'Желен фасул' ИЛИ Product3 = 'Желен фасул'.
Вместо да имаме една маса, която да събере цялата информация заедно, трябва да имаме три маси, всеки от които има отделна информация. В този пример бихме искали таблица с поръчки с информация за самата поръчка, таблица Продукти с всички наши продукти и таблетка ProductOrders, която свързва продуктите с поръчката.
| OrderID | Клиентски номер | Дата на поръчка | Обща сума |
| 1 | 7 | 24.01.17 | 19.99 |
| 2 | 9 | 01/25/17 | 24.99 |
| Идентификация на продукта | продукт | Броя |
| 1 | Плюшени мечета | 1 |
| 2 | Желирани бонбони | 100 |
| ProductOrderID | Идентификация на продукта | OrderID |
| 101 | 1 | 1 |
| 102 | 2 | 1 |
Забележете как всяка таблица има свое уникално ID поле. Това е първичният ключ. Ние свързваме таблици, като използваме стойност на първичен ключ като чужд ключ в друга таблица. Прочетете повече за първичните ключове и чуждите ключове.
Грешка в базата данни 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 St, Остин, Тексас | (215) 545-5545 | Остин Даунтаун | (212) 421-2412 |
Въпреки че тази таблица може да изглежда така, сякаш тя е свързана с отделния продавач, тя всъщност има таблица, вградена в таблицата. Забележете как се повтарят Office и OfficeNumber с "Austin Downtown". Какво ще стане, ако се промени телефонен номер на офиса? Трябва да актуализирате цял набор от данни за една промяна на информацията, която никога не е добре. Тези полета трябва да бъдат преместени на собствената им маса.
| SalesID | първи | последно | адрес | Телефонен номер | OfficeID |
| 1 | Сам | Елиът | 118 Main St, Остин, Тексас | (215) 555-5858 | 1 |
| 2 | Алис | ковач | 504 2nd Street, Ню Йорк, Ню Йорк | (211) 122-1821 | 2 |
| 3 | Джо | енория | 428 Aker St, Остин, Тексас | (215) 545-5545 | 1 |
| OfficeID | офис | OfficeNumber |
| 1 | Остин Даунтаун | (212) 421-2412 |
| 2 | Ню Йорк (Изток) | (211) 855-4541 |
Този тип дизайн също ви дава възможност да добавяте допълнителна информация към таблицата на Office без да създавате кошмар за бъркотия в таблицата за продажбите. Представете си каква работа би било просто да следите уличния адрес, град, държава и пощенски код, ако цялата тази информация е била в таблицата с лица за продажби!
Грешка в базата данни # 3: Поставяне на две или повече части от информацията в едно поле
Включването на информацията за офиса в таблицата с лица за продажби не е единственият проблем с тази база данни. Адресното поле съдържаше три елемента на информация: улица, град и държава. Всяко поле в базата данни трябва да съдържа само една информация. Когато имате няколко броя информация в едно поле, може да стане по-трудно да се потърси информация в базата данни.
Например, какво ще стане, ако искаме да проведем заявка за всички хора от Остин? Трябва да търсим в полето за адрес, което е не само неефективно, но може да върне лоша информация. В края на краищата, какво ще стане, ако някой живее на улица Остин в Портланд, Орегон?
Ето какво трябва да изглежда таблицата:
| SalesID | първи | последно | Адрес 1 | Адрес2 | град | състояние | цип | телефон |
| 1 | Сам | Елиът | 118 Main St | Остин | TX | 78720 | 2155555858 | |
| 2 | Алис | ковач | 504 2-ри Св | Ню Йорк | Ню Йорк | 10022 | 2111221821 | |
| 3 | Джо | енория | 428 Aker St | Ап 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. Прочетете повече за правилното индексиране на базата данни.