Какую из этих двух настроек базы данных я должен выбрать?

У меня есть 3 типа контента: блоги, пресс-релизы и напоминания. Все они имеют body и entered by полями. В блогах и пресс-релизах есть поле title , в котором отсутствует напоминание, а на напоминаниях – hour поле, в котором отсутствуют блоги и пресс-релизы. Это то, что выглядит в табличном формате, поэтому вам легко увидеть …

  blog press release reminder --------------------------------------------------- entered by field yes yes yes body field yes yes yes title field yes yes -- time field -- -- yes

Я создаю основную таблицу под названием content которая ссылается на специализированные таблицы. Я думал о 2 структурах

Первая структура … Вот как я использую систему управления контентом, но я не хочу слепо следовать за ними, потому что мои потребности не совпадают. Поместите ВСЕ общие поля в основную таблицу content . Таким образом, таблица content не будет иметь type id type и type id для ссылки на специализированные таблицы, таблица content также будет иметь общие поля, такие как body и entered by . Остальные 3 таблицы имеют только свои уникальные поля.

 content table B=blogs table PR=press releases table R=reminders table ------------------------------------------------------------------------------ id id id id type=B/PR/R title title hour type id body entered by

Вторая структура. таблица content содержит только type и type id необходимые для ссылки на другие 3 таблицы. Это означает, что общие поля повторяются в трех таблицах.

 content table B=blogs table PR=press releases table R=reminders table ------------------------------------------------------------------------------ id id id id type=B/PR/R entered by entered by entered by type id body body body title title hour

С чем мне пойти? Я думал, что первая структура лучше, потому что я могу искать весь контент, будь то блог или пресс-релиз или напоминание для определенного слова. Мне все равно придется искать в других таблицах, если я хочу искать title доступное только для blogs и press releases , но …

Итак, какая структура лучше, и почему вы так думаете? Я также открыт для других идей или улучшений, которые отличаются от этих 2.

Solutions Collecting From Web of "Какую из этих двух настроек базы данных я должен выбрать?"

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

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

Таким образом, вместо этого ваша таблица содержимого просто становится (nn = not null, n = nullable) id (nn), тип id (nn), type (nn), body (nn), введенный (nn), title (n), час (п). Основная причина, по которой я обычно нахожу это для этого, заключается в том, что если разные сущности данных, которые вы создаете, настолько похожи, что со временем они будут сливаться. Например, напоминания в это время не требуют названия, но в будущем это может быть.

Первая структура является классическим подтипом типа супертипа и рекомендуется. Я бы просто предложил называть первичные ключи с полным идентификатором таблицы, таким как ContentID чтобы избежать возможной путаницы.

alt text

Я бы скорее пошел без какого-либо поля типа, вместо этого создав четыре таблицы: контент, блоги, пресс-релизы и напоминания. Содержимое имеет общие поля, введенные, тело и название. Для каждого из блогов, pressreleases и напоминаний, у них есть идентификатор, который является первичным ключом, а также внешним ключом для идентификатора содержимого. Это делает соотношение 1: 1 «is-a». напоминание может иметь дополнительное поле времени. Чтобы определить, какой тип записи представляет собой строка контента, выполните выбор соединения.

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

Я думаю, вы должны думать об общих полях. Нужно ли им соответствовать?

Если им нужно соответствовать, проще просто поместить его в одну таблицу.