barserСкажите, пожалуйста, какие могут быть 'подводные камни' при следующей организации таблиц БД.
(используется СУБД Oracle 11, NHibernate 2.1)

Основная таблица 'documents' содержит поля, общие для всех видов документов. Например, 'дата создания', 'автор' и т.п.

На уровне приложений работа ведется с экземплярами подклассов документа (например, 'документ-договор' или 'документ-распоряжение').

Каждому подклассу в БД соответствует своя таблица, одно из полей которой - ссылка на id документа в таблице documents. Словом, реализована так называемая схема наследования 'table-per-subclass' (как в учебниках).

Пока всё работает как нужно, но на данный момент существует не так много подклассов документов. Меня интересует, что может произойти при росте их числа.

Конкретно - настораживает следующее:
типичный запрос
транслируется в SQL-запрос с join'ами таблицы основного класса и всех таблиц подклассов.
При добавлении подкласса соответственно добавится еще один inner join.

В принципе, мне кажется для конкретных ситуаций можно будет добавить методы в репозитории документов, не использующие эти join'ы, но хотелось бы знать, чего ожидать, может, не стоит вообще 'париться'... Или наоборот придется полностью менять модель данных?
Кто-нибудь наверняка же проходил через подобный этап в проектировании/разработке.

p.s. На уровне модели данных объединение всех типов документов базовым классом 'document' весьма удобно и представляется мне правильным.
На всякий случай добавлю, что разрабатываемый продукт не относится к OLTP-системам (наверное, это уже и так понятно :) )

Повторюсь, используется СУБД Oracle 11g. Может быть, гуру подскажут, существенные особенности реализации inner join в нём. Когда идет, например, выборка единственной строки по конкретному id, но с n inner join'ами ( в n-1 из которых строки 100% не будет)... Или вариант с 'пэйджингом' - когда на странице отображается около 20 документов различных подклассов.

Спасибо!

Вот здесь был спор но только для MS SQL
http://www.sql.ru/forum/actualthread.aspx?tid=405678&hl=%ee%ee%ef

Ничего страшного в такой структуре не нашли, главное правильно спланировать.
У нас вот уже два года, как система с такой структурой внедрена, тоже MS SQL, и проблем пока не видно, подклассов больше 50. Размер базы около 1 Гб, конечно не много, но тормозов не наблюдается.
Соответственно, если грамотно подойти к проектированию, все будет нормально. Единственное мы не использовали Хибирнейт. Используем хранимые процедуры для доступа к данным, к классам документов.