Схема базы данных - организовать по объекту или данным?

Question

Я делаю рефакторинг ужасно переплетенной схемы БД, она не слишком нормализована; только со временем стал некрасивым и не очень хорошо выложенным.

Существует несколько таблиц (форумы, сообщения на форуме, сообщения об идеях, записи в блогах), которые имеют практически идентичные структуры данных и состав, но разделены просто потому, что они представляют разные "объекты" с точки зрения приложений. Моя первоначальная реакция - поместить все, что имеет одинаковую структуру данных, в одну таблицу и использовать столбец «тип», чтобы различать данные при выполнении выбора.

Готов ли я к падению, приняв этот подход «все в одном» и позволяя (потенциально) многим частям приложения получить доступ к одной и той же таблице? К вашему сведению, я не вижу, чтобы эта база данных выросла до более чем 20 МБ в следующем году или около того ...

Answer 1

Существует три основных способа хранения иерархии наследования объектов в реляционной базе данных. У каждого есть свои плюсы и минусы. См:

• http://www.martinfowler.com/eaaCatalog/singleTableInheritance.html
• http://www.martinfowler.com/eaaCatalog/classTableInheritance.html
• http://www.martinfowler.com/eaaCatalog/concreteTableInheritance.html

Книга тоже великолепна. К счастью, глава 3 - «Сопоставление с реляционными базами данных» - свободно доступна в качестве примера главы Вы можете прочитать больше о компромиссах там.

Answer 2

Не слишком полагайтесь на «перспективу приложений», она имеет тенденцию меняться с течением времени в любом случае. Часто к базам данных также обращаются разные приложения, и они обычно переживают их все ...

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

Answer 3

Раньше мне не нравился этот подход «все в одном», но после того, как я был вынужден использовать его в сложном проекте несколько лет назад, я стал фанатом. Если вы правильно проиндексировали таблицу, производительность должна быть в порядке. Вам понадобится индекс для столбца типа, чтобы ускорить сортировку, например, по операциям типа.

Теперь я обычно рекомендую использовать одну таблицу для хранения похожих объектов. Тогда единственный вопрос заключается в том, хотите ли вы использовать подтаблицы для хранения данных, относящихся к определенному типу объектов? Ответ на этот вопрос действительно зависит от того, насколько различна структура каждого типа объекта и сколько типов объектов у вас будет. Если у вас есть 50 типов объектов с сильно различающимися структурами, вы можете рассмотреть вопрос о сохранении только согласованных частей объекта в основной таблице и создании вложенной таблицы для каждого типа объекта.

В вашем примере, однако, я думаю, что вы будете в порядке, просто сложив все это в одну таблицу.

Подробнее см. Здесь: http://www.agiledata.org/essays/mappingObjects.html