Как верно проектировать базу данных?

Здравствуйте.
Вопрос в следующем: есть проект, который содержит достаточно много таблиц (не сотни, конечно, десятки, но работать уже не комфортно). Периодически встают задачи, которые требуют добавления новых таблицы или колонок и т.д. Существует дилема (для меня) создавать нормализованные таблицы или нет. Просто, если да, тогда это еще добавится 3-4 таблицы, а если нет, тогда всего одна, или вообще все данные в одну колонку запихнуть.
Хотелось бы узнать субъективное (личное мнение) разработчиков, потому что ответ на этот вопрос обычно звучит следующим образом - смотрите сами, в зависимости от вашего проекта, опыта и т.д.
Спасибо.
  • Вопрос задан
  • 560 просмотров
Решения вопроса 5
@mletov
Все упирается в объемы данных. Если предполагаемое количество записей не будет исчисляться миллионами или даже десятками миллионов, то лучше придерживаться нормализации. Бардака будет меньше. Иначе да, денормализация или всякие решения типа nosql.

Так же свою лепту вносит заказчик.
Например, нужно выводить сводные данные за некие отчетные периоды. С т зрения программирования, лучше считать динамически на основе правильно нормализованной базы. Добавилась в период строчка - пересчитатли общий результат за этот период. Но, с т зрения учета, заказчики часто требуют, что если период закрылся - то результаты по нему не пересчитывают, даже если в этот период впихнули еще строчек задним числом. Приходится добавлять еще одну таблицу вопреки нормализации.
Ответ написан
@lega
или вообще все данные в одну колонку запихнуть.

На клиенте "объект" можно распарсить из любого вида, даже если это одна колонка сжатых данных в gzip.

Вопрос в индексах, вам нужно хранить данные так, что-бы можно было сделать на них индексы, и любые запросы выполнялись мгновенно.
В итоге если вам надо добавить например список телефонов к элементу таблицы, и вам не нужно делать по ним поиск, проверку уникальности, группировки и т.п. то нет смысла плодить отдельную таблицу под них, удобнее использовать json или массив. (хотя в некоторых БД уникальность и поиск можно сделать и для json/массива).

В итоге будет быстрее работать, т.к. нет JOIN, экономия RAM т.к. нет доп. индекса для JOIN, да и вообще удобней т.к. меньше сущностей.
Ответ написан
Комментировать
Melkij
@Melkij
PostgreSQL DBA
Если нужна таблица - должна быть таблица.

Postgresql предоставляет шикарную возможность разделить базу данных на схемы. Есть пачка таблиц, описывающая какую-нибудь сущность? Перенесите их в отдельную схему и пусть не мешаются в public. Таблицы аггрегации? Выкиньте их в отдельную схему.
Замечательно помогает, если становится многовато таблиц (несколько десятков разве много?).
Правда, если вы любитель всякого орм, ваша библиотека может не уметь схемы.
Ответ написан
Комментировать
terrier
@terrier
Пугаться "большого" количества таблиц не стоит, особенно если "большое" - это десятки.
Если вам некомфортно работать с таким числом таблиц , настройте свои инструменты ( или возьмите нормальные, если текущие не тащат )
Ответ написан
Комментировать
MetaAbstract
@MetaAbstract
Архитектор информационных систем и баз данных. Ful
Конечно нормализованные. На денормализованных таблицах у Вас Join не будет и Вам придется либо синхронизировать теоретически идентичные данные в разных полях, либо пилить свой движок SQL.
Ответ написан
Комментировать
Пригласить эксперта
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы