Моят съвет относно моделирането на данни е:
- Трябва да предпочитате незадължителни (с нулеви стойности) колони пред 1:1 присъединявания общо казано . Все още има случаи, когато 1:1 има смисъл, обикновено се върти около подтип. Хората са склонни да бъдат по-придирчиви, когато става въпрос за нулеви колони, отколкото за присъединяванията;
- Не правете модел също непряко освен ако наистина оправдано (повече за това по-долу);
- Предпочитане на присъединяванията пред агрегирането. Това може да варира, така че трябва да се тества. Вижте Oracle срещу MySQL срещу SQL Server:Агрегация срещу присъединяване за пример за това;
- Съединяванията са по-добри от N+1 избрани. Изборът N+1 е например избор на поръчка от таблица на база данни и след това издаване на отделна заявка за получаване на всички договорени позиции за тази поръчка;
- Мащабируемостта на съединенията е обикновено проблем е само когато правите масови селекции. Ако изберете един ред и след това го присъедините към няколко неща, рядко това е проблем (но понякога е);
- Външните ключове трябва винаги да бъдат индексирани, освен ако не се занимавате с тривиално малка таблица;
Още в Грешки при разработването на бази данни, направени от разработчиците на приложения .
А относно директността на модела, нека ви дам пример. Да приемем, че проектирате система за удостоверяване и оторизация на потребителите. Едно свръхинженерно решение може да изглежда така:
- Псевдоним (идентификатор, потребителско име, user_id);
- Потребител (идентификатор, ...);
- Имейл (id, user_id, имейл адрес);
- Вход (id, user_id, ...)
- Роли за вход (id, login_id, role_id);
- Роля (идентификатор, име);
- Привилегия на роля (id, role_id, privilege_id);
- Привилегия (идентификатор, име).
Така че имате нужда от 6 присъединявания, за да получите от въведеното потребителско име до действителните привилегии. Разбира се, може да има действително изискване за това, но по-често този вид система се въвежда поради извиване на ръка от някои разработчици, които смятат, че някой ден може да се нуждаят от нея, въпреки че всеки потребител има само един псевдоним, потребителят за влизане е 1 :1 и така нататък. По-просто решение е:
- Потребител (идентификатор, потребителско име, имейл адрес, тип потребител)
и добре, това е. Може би, ако имате нужда от сложна ролева система, но също така е напълно възможно да не го правите и ако го направите, е сравнително лесно да влезете (типът на потребителя става външен ключ в таблица с потребителски типове или роли) или като цяло е лесно да съпоставите старо към ново.
Това е нещо за сложността:лесно се добавя и трудно се премахва. Обикновено това е постоянно бдение срещу непредвидена сложност, което е достатъчно лошо, без да върви и да го влошава чрез добавяне на ненужна сложност.
