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

Question

У меня есть основная концепция - почтовое сообщение и две производные концепции:

• сгенерированные по шаблону электронные письма
• электронные письма в свободной форме

Я думаю о создании трех таблиц для хранения данных, и мне нужно ваше мнение по этому вопросу (если это плохо, если это хорошо, как это можно улучшить и так далее):

---

MailMessages

• Id [int] идентификатор (автоинкремент) PK
• ToAddress [varchar (300)]
• IsTemplateBased [бит]
• TemplateId [int] обнуляемый FK
• MailBodyId [int] обнуляемый FK (TemplateId должен быть нулевым, а MailBodyId должен быть ненулевым или наоборот)
• StatusId [tinyint] FK

MailParams

• MailMessageId [int] PFK
• ParamNumber [tinyint]
• Значение [nvarchar (4000)]

MailBody

• MailMessageId [int] PFK
• FromUsername [varchar (30)]
• FromDomainId [tinyint] FK
• PlainTextContent [nvarchar (max)]
• HtmlContent [nvarchar (max)] обнуляемый

---

Здесь приведено несколько объяснений:

• Я быкак максимально нормализованный дизайн
• Битовый (логический) столбец IsTemplateBased можно опустить, а характер почтового сообщения можно определить из TemplateId и / или MailBodyId (т. е. если TemplateId не равен NULL, то это шаблонна основе), но я думаю, что эта ненормализация (?) может быть полезна для производительности
• Причина наличия двух столбцов (FromUsername и FromDomainId) заключается в применении правил проверки работоспособности электронной почты - я не рассматриваю наличие единогоколонка (FromAddress) как подходящая

---

Сказав все это, что вы думаете, дорогие читатели?

Answer 1

Вот пример модели "стандартный тип / подтип", отмеченной @Philip Kelley выше:

У вас есть

• SupertypeType. Таблица доменов, ограничивающая домен идентификатора типа.

• Supertype. Общий супертип.В этой таблице существует строка для каждого экземпляра одного из экземпляров подтипа.Он содержит идентификатор объекта (SupertypeID), идентификатор типа объекта (TypeID) и атрибуты, общие для всех подтипов.

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

Чтобы перечислить все элементы, запросите только таблицу супертипа.

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

Приложение. Если вам нужен плоский, денормализованный вид всего наборапросто оставьте соединение между подтипами:

select *
from Supertype     t
left join Subtype1 t1 on t1.SupertypeID = t.SupertypeID
left join Subtype2 t2 on t2.SupertypeID = t.SupertypeID
left join Subtype3 t3 on t3.SupertypeID = t.SupertypeID

Теперь вам не нужно многократные запросы. Вы обменяли это на необходимость иметь дело с нулем.

Answer 2

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

Answer 3

Вы можете упростить и сделать его более похожим на стандартную модель типа / подтипа, например:

• Начните с MailMessags.Id в качестве первичного ключа таблицы «type»
• Имейте IsTemplateBased в качестве индикатора типа, чтобы сказать, что это за электронная почта.(Я бы сделал это очень маленьким, чтобы в будущем можно было использовать его в индексах и для других типов.)
• Удалите TemplateId и MailBodyId, они вам не понадобятся.
• ВТаблица «subtype» MailParams, установите MailMessageId в качестве PK и FK, ссылающегося на MailMessages.Id
• . Сделайте то же самое для MailBody.MailMessageId

Вместо трех различных суррогатных ключейсоответственно больше шансов на ошибку и путаницу), теперь у вас есть только один для управления.