WiRuc pkarklinПример с 5ю уровнями:

Объект->Контракт->Договор хозяйственной деятельности->Авторский договор->Авторский договор (исключительные права)

Понятно, что при желании можно сделать и 10 уровень наследования, но все-таки с каждым уровнем увеличивается кол-во вставок, необходимых для создании записи в сущности. Нахождение нескольких сущностей в одной таблице уже несколько меняет это дело.Sorry за вмешательство. Выкиньте из схемы pkarklin первый уровень, т.е., "Объект" и получиться с большой степенью вероятности такое же разбиение при стандартном реляционном подходе. Если, конечно, не идти радикальным путем, когда каждый вид контракта рассматривается как отдельная сущность и тогда появятся 10, если не больше, различных невзаимосвязанных таблиц. И тогда возникают сложности для получения сводных отчетов, сложности ссылочного характера, те самые FK.
Спич к тому, что по большому счету, количество "уровней" при такой схеме может не так уж и сильно отличаться от традиционного подхода.

WiRucЯ понимаю это несколько по-другому. Объектная модель предполагает расширение аттрибутики от уровня к уровню. Т.е., если моделировать скажем накладные, то наверное была бы такая схема в ООП - Объект->Табличный документ->Товарные накладные->Расходные накладные и Объект->Табличный документ->Товарные накладные->Приходные накладные. Если не заморачиваться с ООП, то обычно Приходные и Расходные накладные это просто 2 разные таблицы (с некоторым подмножеством совпадающих полей), либо вообще 1 таблица с полем, определяющим вид накладной. Т.е. в случае ООП кол-во таблиц для описания сущности будет больше.То, что больше, сомнению не подвергалось, если только не перейти на радикальный EAV, там вообще число таблиц может быть просто фиксировано один раз и навсегда.
Упомянутая Вами схема с накладными действительно проще, но до тех пор, пока не требуются связи между документами, при которых могут возникать ссылки на совершенно разные сущности-документы, при этом, как правило, либо появляются ссылочная целостность на сложных триггерах, учитывающих допустимость даного значения поля-ссылки, и при появлении каждого нового типа документов их придется переписывать, либо куча полей, по которым будет возможно FK, но, возможно, только по одному из них, что потребует дополнительных проверок, если хотим "по честному". И при этом, новой сущность опять же потребует модификацию схемы, меняя количество полей и корректируя проверки.
Сводная отчетность также не добавляет простоты, когда приходиться через union объединять стада разношерстных таблиц, и при появлении новых сущностей опять же будем вынуждены ее переписывать.
Единственный, IMHO, здравый путь для борьбы с этим комом проблем, введение суперсущностей, той или иной степени абстрактности. И в результате, незаметно для себя мы получаем ту же самую иерархию, ну может быть на один-два уровня пониже.
Понятно, что если мы автоматизируем какой-нибудь магазинчик, склад, да мало ли еще чего, то такой подход возможно будет эквивалентом пушки по воробьям. Но когда речь идет об автоматизации крупного холдинга, к примеру, то без иерархии сущностей работы будет больше, IMHO.
В конце концов, компьютеры и сервера должны работать, облегчая нашу жизнь, а не мы все время искать пути, как бы поменьше их загрузить Хотя, допускаю, что мысль выглядит спорной.

WiRucХотите максимум производительности - будете рисовать отдельные сущности, ничего не попишешь. Палка о двух концах.Совершенно верно. Собственно, в этом топике суть была высказана на первой странице, IMHO. Остальное из разряда "верю-не верю", "нужно-не нужно". Нужна гибкость, настраиваемость, минимум вмешательств в схему БД при появлении новых сущностей, выбираете один подход, нужна максимальная производительность - другой. Скажем биллинг я лично не рискнул бы делать по объектно-подобной модели. Но есть достаточно много документоориентированных областей, где она, возможно, может оказаться более предпочтительной.