Некоторые принципы проектирования и организаций реляционных БД

Хотелось бы поделиться своим опытом в сфере качественного и эффективного построения реляционных БД. Я расскажу свою видимость и концепцию создания различных структур БД. У меня за спиной в этом деле есть опыт и мне хотелось бы им поделиться в силу того, что по этой специфики у совсем зеленых новичков очень много вопросов. Да, в Инет уже существует огромное множество различной литературы по правильному проектированию и корректному развертыванию БД, и написав этот пост я не стану первооткрывателем, но все же хочу все подытожить и написать всю суть в одном посте. Думаю для кого-то это будет удобнее, чем множество толстых книг с примерами на 5 стр.

Ниже приведены основы правильно (по моему мнению) построения баз данных. Под словом правильные я понимаю самые тривиальные понятия программирования, а именно базы должны быть максимально: минимальны в размерах, четко разложены и сконцентрированы, а так же явно отличны друг от друга без допускаемых путаниц и неразберих. Сделаю поправку на то, что тут я описываю самый базис и для опытных администраторов баз данных эта информация скорее всего окажется бесполезной. Так же тут я описываю все стандартно и поверхностно т.е. в целях каждого конкретного проекта могут быть условия, которые явно заставляют нарушить описанные ниже правила. Плюс ко всему выше сказанному, открыто заявляю, что эти принципы созданы мной как результат моих работ и различных экспериментов и они ни коим образом не претендуют на правду в последней инстанции.

Основные принципы баз данных:

В базе не должно быть одинаковых по структуре таблиц. Т.е. если ваша база к примеру состоит из двух одинаковых по структуре таблиц студентов (Students 1 & Students 2) и различаются лишь тем, что в одной таблице студенты из одного факультета, а в другой из другого, то лучше объединить эти две таблицы в одну (Students) и создать дополнительный столбец (faculty) в котором будет указан факультет каждого конкретного студента.

В базе вообще не должно быть пустых ячеек. Вернемся к первому примеру со студентами и факультетами. Предположим, что возможна такая ситуация когда студента (абитуриента) вносят в базу (таблица Students), но его факультет (столбец faculty в таблице Students) по каким-либо причинам еще не известен и получается такая ситуация когда у строки (студента) есть пустая ячейка (столбец faculty) столбик с факультетом. В этом случае целесообразнее создать отдельную таблицу (faculty students) в которой будет 2 столбца: id студента и id (или название) факультета. А столбец с факультетами (faculty) удалить из таблицы студентов (Students) т.к. это функционал выполняет отдельная (только что созданная) таблица (faculty students). В этом случае студента мы вносим в таблицу студентов (Students) но в таблицу факультетов (faculty students) его не добавляем. Таким образом получается, что если в таблице (faculty students) конкретного студента еще нет, то его факультет пока не определен. В дальнейшем можно легко добавить новую строчку в таблицу (faculty students).

В базе не должно быть повторяющихся (дублирующихся) данных. Т.е. если у вас основная таблица статей вашего сайта состоит из столбца основного текста статьи — Text и столбца Description, в котором хранится кусок текста из столбца Text, то в этом случае лучше не использовать (удалить) вспомогательный столбец Description т.к. у вас в базе уже хранится весь текст. Т.е. у вас явный дубликат уже имеющейся информации, который лишний раз увеличивает объем базы. В этом случае лучше при выводе страницы в мета теге Description выводить вырезанную из Text информацию. Ваша база данных не должна решать ваши проблемы в силу того, что вы не смогли программно описать логику вырезания текста. Она лишь хранит данные и больше ничего, все остальное это ваш код!

Первые 2 правила противоречат этому, третьему, правилу т.к.:

  1. Для решения первого: в столбце (faculty) будут повторяться идентификаторы (или названия) факультетов.
  2. Для решения второго: в таблице (faculty students) в разных строках будут повторяться id (или названия) факультетов.

В этом случае необходимо все взвесить и решить какое из зол меньше, т.е. какой вариант решения будет меньше громоздить БД и увеличивать её размер в целом.

Пока на этом всё. Как вспомню про остальные важные правила – тут же их допишу в этот пост.