Да собственно у меня ядро системы тоже по большей части готово + готов инструмент для создания новых типов и объектов. Редактирование объектов точно также реализуется автоформами. Вообще у меня возникло впечатление, что наши системы довольно похожи по структуре.
Просто решил поинтересоваться опытом в создании и эксплуатации подобных систем и как они работают с большими объемами данных.

А у нас собственно есть инвестор, на чьи деньги она и пишется.
Первая версия писалась для внутренних нужд, новую собираемся продавать.
Продавать что-то коробочное на российском рынке очень тяжело, а системы такого рода вообще нереально.
Можно продавать внедрения таких систем, чем мы и собираемся заниматься. Есть уже наработанная функциональность для CMS, зачатков документооборота и CRM. Они реализованы для старой версии системы, где маппинг производился вручную, теперь стоит задача перенести их на новую версию.
Вы если не ошибаюсь, уже около года доводите свою систему до товарного вида? За это время так ничего и не получилось? Если система действительно стоящая, то думаю можно было бы на ее внедрениях и консалтинге попробовать что-то заработать, а саму систему сделать opensource'ной.
Но для этого нужно еще и соответствующую функциональность реализовать и организационно это все оформить.
Продавать коробку без серьезных вложений в ее продвижение не получится, а не имея опыта в таких делах почти 100% вероятность что эта затея провалится. У нас практически нет рынка для таких продуктов.
Есть рынок внедрения CRM, CMS, ERP, документооборота и т.п. Если организуете сеть партнеров по принципу 1С, тогда можно будет говорить о продаже коробок :).

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

TemplarНет, многие продукты позволяют производить как прямой (классы --> схема БД), так и обратный инжиниринг (схема БД --> классы). С разной степенью автоматизма: от полного до ручного.
Да я собственно в курсе, что позволяют, причитайте внимательно - обычно используется . В тех ORM, которые я смотрел, функциональность "обратного инжениринга" плохо подходит для нашей задачи.

funikovyuri VladiCh

аблица, в которой хранятся OID объектов - это таблица базового типа. Таблицы дочерних типов относятся к ней 1-1. Как навешать на это все обычный OR-маппинг?

Интересно и какие ORM вы изучили чтобы делать выводы о невозможности их использования в вашей задаче?
Пожалуйста не вырывайте мои слова из контекста и прочитайте внимательнее исходное сообщение. Там говорилось не только про отношения 1 к 1.
Еще я говорил не про невозможность, а про то, что они плохо подходят для этой задачи. Смотрел я nHibernate, atoms framework, xpress persistent objects. критерием выбора была бесплатность или низкая стоимость соответствующих инструментов.
По поводу вопросов - я не просил дать какую-то объективную оценку в секундах, порядках и т.п., просто спрашивал мнение людей, делавших что-то подобное. В чем это выразить - на ваше усмотрение. Можно это выразить например в сравнении с каким-нибудь другим вариантом реализации наследования.

Разумеется я читал про разные варианты реализации наследования. Просто читать - это одно дело, а реальный опыт использования - другое. Хотел я услышать именно про примеры использования.
Препятствует использованию orm разделение атрибутов объектов на две группы. Атрибуты одной группы хранятся в связанной с типом таблице. Атрибуты другой группы (как правило это текстовые атрибуты) - в отдельной таблице. В этой таблице хранятся атрибуты этой группы для всех типов. Каким образом реализовать такую модель при помощи orm?

1. Таблица на каждый класс (Class table inheritance) - хранятся только свои атрибуты, родительские достаются через отношение 1 к 1.
2. Таблица на каждый конкретный класс (Concrete table inheritance). - копирование атрибутов родителя в подклассах.
3. Таблица на иерархию классов (Single table inheritance) - когда все атрибуты всех классов хранятся в одной таблице.

Ну и еще можно например 1 и 3 подходы смешивать в пределах разумного, т.е. делать одну таблицу на небольшую иерархию классов, а эту иерархии могут наследоваться от одного предка как class table inheritance

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

Вот поэтому я и написал что плохо подходит.
Классы у нас может создавать обычный (ну почти обычный) пользователь. Перекомпиляции приложения для этого не требуется. Атрибуты добавлять тоже. Как это сочетается с ручным маппингом?

Существующие средства маппинга работают по всем трем вариантам + их вариации, но они нам все не очень подходят, т.к. в нашей системе помимо маппинга хранятся свои метаданные, которые могут изменяться из приложения + не для каждого типа требуется своя таблица (если все атрибуты типа - т.н. "статические"). То есть это комбинация стандартного маппинга с class table inheritance и хранением метаданных как объектов системы и хранением всех "статических" атрибутов всех объектов в отдельной таблице.

Поподробнее пожалуйста.... Ну раскрутили вы его на сервере в ту же отдельную таблицу, как сейчас и сделано, а выборки потом как делать?
Оно кстати сейчас практически так и делается, только раскручивается из xml не на сервере БД, а в приложении. И сериализуются в XML все атрибуты, а не только дополнительные и гоняется он через веб-сервис. Но это уже другая история :). Кстати, число и структура их заранее известна. Они также описаны в метаданных. Там не все так просто получается :)