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

Question

[Артем Кисленко]

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

Answer 1

[mletov]

Все упирается в объемы данных. Если предполагаемое количество записей не будет исчисляться миллионами или даже десятками миллионов, то лучше придерживаться нормализации. Бардака будет меньше. Иначе да, денормализация или всякие решения типа nosql.

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

Comments

[Melkij]

Всего лишь десятки миллионов? Для postgresql? Вы размещаетесь на raspberry pi?

[mletov]

Melkij: Ок, озвучьте другую цифру, начиная с которой стоит задумываться о денормализации)

[Melkij]

Когда не укладываетесь в желаемую производительность - вот тогда и денормализовывать. Какую-то аггрегацию нередко оправдано добавлять сразу, как появилась необходимость её выводить на веб-морде, например, статистику чего-нибудь для графиков. Меняется только хвост, а начало статично. При том, таблиц аггрегации может быть и несколько. Это может быть и материализованное представление, когда наконец сделают инкрементное обновление - но тоже своего рода таблица. Теоретически, это денормализация, вот только для исходных данных нормальная форма остаётся как есть. Добавляется только предварительно рассчитываемый аггрегат.

Answer 2

[lega]

или вообще все данные в одну колонку запихнуть.

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

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

В итоге будет быстрее работать, т.к. нет JOIN, экономия RAM т.к. нет доп. индекса для JOIN, да и вообще удобней т.к. меньше сущностей.

Answer 3

[Melkij]

Если нужна таблица - должна быть таблица.

Postgresql предоставляет шикарную возможность разделить базу данных на схемы. Есть пачка таблиц, описывающая какую-нибудь сущность? Перенесите их в отдельную схему и пусть не мешаются в public. Таблицы аггрегации? Выкиньте их в отдельную схему.
Замечательно помогает, если становится многовато таблиц (несколько десятков разве много?).
Правда, если вы любитель всякого орм, ваша библиотека может не уметь схемы.

Answer 4

[terrier]

Пугаться "большого" количества таблиц не стоит, особенно если "большое" - это десятки.
Если вам некомфортно работать с таким числом таблиц , настройте свои инструменты ( или возьмите нормальные, если текущие не тащат )

Answer 5

[Артемий]

Конечно нормализованные. На денормализованных таблицах у Вас Join не будет и Вам придется либо синхронизировать теоретически идентичные данные в разных полях, либо пилить свой движок SQL.