Подробнее о наследовании и проектировании баз данных

Question

Предисловие: Хотя я не думаю, что это точно дубликат, не стесняйтесь закрывать, если считаете, что это слишком похоже на этот предыдущий вопрос от меня .

Я перефакторизовал дизайн базы данных, где у меня есть четыре суперкласса таблиц, из которых должны быть получены некоторые другие.Теперь я сталкиваюсь с сомнением относительно того, следует ли включать (четыре) таблицы «идентификации типов» и присоединять их к каждому из суперклассов, чтобы идентифицировать подтип каждой записи.Проблема в том, что без них дизайн уже довольно большой (14 таблиц), и, поскольку одно из требований состоит в том, что оно должно быть легко расширяемым, я боюсь, что в итоге получится 30 или более таблиц.Короче говоря, можно / можно ли исключить этот тип таблиц из дизайна?

PS: Цель состоит в том, чтобы иметь очень легко расширяемый дизайн.Например, одна из таблиц представляет собой сообщение , подтипами которого могут быть SMS, MMS, электронная почта, твит , сообщение на Facebook и так далее.Конечно, общая информация идет о суперклассе , а остальная информация попадает в другие несколько таблиц по мере необходимости.

Answer 1

30 таблиц легче понять, чем 30 000 строк кода.Я работал с базами данных, в которых более 100 таблиц.Я бы не беспокоился о 30.

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

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

Как вы указали, данные, общие для всех специализированных объектов, попадают в общую таблицу (суперкласс), в то время как данные, свойственные данному специализированному объекту, попадают в соответствующую специализированную таблицу (подкласс).Хитрость в дизайне заключается в том, как таблицы подклассов получают первичный ключ.Первичный ключ для таблиц подкласса не является автоинкрементным числом.Это копия ПК из таблицы суперкласса.Это позволяет легко получить все данные о конкретной специальности, просто выполнив объединение.Это также делает ненужным включение полей типа, поскольку каждая специализированная таблица покрывает свой собственный подкласс.

Это немного сложно настроить и обновить, но оно окупается во время поиска.

Answer 2

Все зависит от требований.
Невозможно определить, много ли 14 таблиц или нет, не зная требований из базы данных

Относительно производного.Вопрос, который вы должны задать себе, «будет ли операция над всеми сообщениями обычной задачей относительно операций с определенным типом сообщений?».Если ответ «да», то вы должны использовать производный подход, в противном случае лучше иметь разные таблицы (смс, электронная почта и т. Д.) С некоторыми полями, имеющими общее имя.
Относительно реализации.Если вы знакомы с отношением IS-A ERD (отличный способ визуализации вашей базы данных), то общий способ реализации этого заключается в следующем.Таблица сообщений будет содержать все поля, общие для всех сообщений, независимо от их типа.Будет таблица для каждого типа сообщения, и она будет содержать поля, специфичные для этого типа сообщения.Для некоторых запросов это потребует объединения.
Я полагаю, именно это вы и имели в виду в своем вопросе.Если так, то я так считаю лучшим.

Answer 3

Одним из подходов может быть создание базы данных на основе шаблона свойств . Таким образом, вы можете иметь таблицу Messages, которая содержит все общие поля суперкласса, и таблицу MessageProperties, которая позволяет добавлять произвольные свойства к любому экземпляру Message.

В этом случае Message - это SMSMessage, если оно имеет свойства, специфичные для этого типа (например, свойство destinationPhoneNumber). Это заставляет больше работать в коде на стороне сервера, чтобы различать разные типы объектов, но позволяет вам иметь произвольное количество различных Message «подклассов», используя только две таблицы.