Блог

Ну, у меня есть несколько разных типов контента, которые я хочу сделать доступными. Некоторые из них настолько похожи, что я чувствую, что они принадлежат к одной категории. Однако существуют столбцы, которые применяются к одному из типов контента, а не к другим. Должен ли я хранить их все в nodes таблице или мне следует создать новую таблицу для каждого content type ? Должен ли я разбивать таблицы на несовместимые столбцы?

Вот несколько примеров типов контента: книга, запись в блоге, объявление, профиль, история в центре внимания, архивная история, статическая страница, контактная форма, викторина, опрос.

Я думал о разделении таблиц следующим образом:

 post: book, spotlight story, archival story, blog entry

questionnaire: quiz, poll

static: static page, profile  

ad

contact form
  

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

TL; DR: Это зависит.

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

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

Если каждый подтип имеет «небольшое» количество уникальных свойств, может быть так же просто сохранить тип и каждое свойство в одной таблице («наследование одной таблицы»), или если скорость действительно становится проблемой.

Другой вариант — фактически сделать и то, и другое: сохранить реляционную модель, но использовать триггеры для хранения коллекции плоских данных. Я не уверен, что это имеет смысл в вашем случае, поскольку, вероятно, не будет «большого» количества объединений, но для действительно сложных моделей БД это удобно, особенно для отчетности.