Нормализация DB по сравнению с идентификатором данных

Question

У меня есть некоторое представление о нормализации базы данных, и иногда я думаю, что в некоторых случаях существует более элегантное решение, чем одномерный шаблон DATA OBJECT = ONE TABLE (я считаю).

Например: хранение предметов и статических страниц. Эти данные очень похожи, и мы могли бы поместить их в одну таблицу, используя простой столбец с идентификационным номером и из-за разницы, какие данные мы фактически хранящей там будут какие-то пустые неиспользуемые смещ_по_столбцам для каждого типа данных:

id | title(both) | author(article only) | content(both) | datetime(article only) | type(identificator - article/page) 

Является ли этот подход по-прежнему правильны или должна быть таблица для каждой информации независимо от сходства?

Answer 1

Опишите Наследование отдельных таблиц. Это законный образец см http://martinfowler.com/eaaCatalog/singleTableInheritance.html

Преимущества:

• Одна таблица содержит все подтипы.

К недостаткам можно отнести:

• Вы не можете определить NOT NULL ограничения на подтип конкретных столбцов, так как они должны быть обнуляемым.
• UNIQUE или FOREIGN KEY Ограничения на столбцы, специфичные для подтипов, могут не поддерживаться (в зависимости от реализации РСУБД).
• Если у вас много подтипов, в таблице будет много столбцов, большинство из которых будут NULL. Некоторые базы данных имеют ограничение на количество столбцов для данной таблицы. Но в случае MySQL максимальные столбцы на таблицу составляют 4096. InnoDB не хранит NULL, поэтому это не должно быть проблемой.
• Если вы часто добавляете новые подтипы, вам нужно будет ALTER table каждый раз, когда вы добавляете больше столбцов подтипа.

Возможно, вы захотите ознакомиться с альтернативами, такими как Наследование классов таблицы (http://martinfowler.com/eaaCatalog/classTableInheritance.html).