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

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

Плюсы

Сокращается количество таблиц.

Гибкость. Зачастую, в коробочных решениях за счёт контейнерных таблиц вводятся дополнительные атрибуты сущностей, в то время как основные (включённые в коробку) хранятся непосредственно в полях таблиц самих объектов.

Минусы

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

Много соединений — значит большая нагрузка на оптимизатор SQL (внутри СУБД). Особенно учитывая, что присоединяются не справочники, в которых значений мало, а таблицы-контейнеры, в которых записей больше чем в основной таблице. В итоге, СУБД не может оптимизировать план выполнения запроса.

Много записей — значит СУБД от блокировок строк переходит к блокировке таблицы или страниц данных. Это так называемая эскалация блокировок. Есть порог, после которого СУБД считает, что управлять большим числом блокировок строк дороже, чем малым числом блокировок таблиц или страниц.

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

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

Примечание от 2017 г. Однажды я видел решение на основе таблиц-контейнеров в заказном ПО, где в итоге от них отказались. Однако, этот отказ стоил много миллионов рублей и целый год разработки.

Альтернативы

Если разработчик решил, что те или иные атрибуты не будут использоваться при работе с набором записей (что маловероятно, учитывая, как я писал выше, что если бизнес ввёл дополнительный атрибут, значит рано или поздно он захочет по нему отбор или группировку), тогда, почему бы не сохранять значения этих атрибутов в одном XML поле в таблице самого объекта? Извлечь данные из XML нужно будет на стороне приложения, а не СУБД.

Атрибуты, которые могут использоваться в произвольных вариантах (группировка, отбор, отображение в реестре, отображение на форме), должны быть полями в таблице сущности.