> Теперь впору мне удивляться и спрашивать, а что за зверь такой "законченное
> решение" и почему, например, Nexus туда не относится ?

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

> Если с претензией на относительную универсальность.

На мой взгляд, основные из перечисленных задач могут быть решены сразу несколькими способами, большинство из которых имеют право на существование; использование их (способов) может определяться дополнительными требованиями к программному продукту (например, можно выбрать схему локализации, минимизирующую итоговое количество таблиц или реализовать ограничение доступа с быстрой проверкой, но без возможности расширения). А предусмотреть несколько альтернативных вариантов реализации при проектировании структуры базы данных - накладно. К чему это: к сожалению, даже просто формулирование требований - не слишком простая задача; imho сделать это можно только в общих чертах.

> Но одновременно и спрос на "движки" упал.

Не соглашусь. Просто предложений стало больше, спрос естественным образом сегментировался.

> Выбирают готовые решения пусть бы они были даже и на несовершенных
> платформах. Поэтому и дискуссии на эту тему практически сошли "на нет".

Да их и пять лет назад было не много. ;) Что было десять лет назад - не знаю, врать не буду.

> Гипотеза такая. "Движок" нужен для систем класса ИС предприятия (обощенно,
> КИС).

Чем функциональность приложения для маленькой лавчонки с 10 сотрудниками должна глобально отличаться от функциональности приложения для крупного холдинга? Ну да, задач у холдинга будет побольше, требования к производительности серьезнее, а базовая функциональность (т. е. тот самый набор абстрактных требований, который я упоминал) приложения останется неизменной. В простейшем случае эта функциональность определяется системным набором сущностей базы данных и метаописанием объектов базы данных.

> Подрядчику делать платформу ради одного закачика невыгодно. Видимо,
> рентабельность приходит где-то к пятому-десятому проекту, а это уровень
> малотиражного продукта.

Ну почему ради одного заказчика? Если ядро схемы остается неизменным для любой реализации, то новизна проекта сводится к решению дополнительных задач.

> Все больше проектов делается с использованием готовых систем.

Каких, например, если не секрет?

> Спрос на малотиражные системы падает. На "движки" для них, соответственно, тоже.

Возникает закономерный вопрос: а вновь появляющиеся продукты пишутся исключительно благодаря альтруизму разработчиков? Или все-таки они оплачены (пусть частично)?

> точку зрения на конкретный (необходимый/достаточный) состав "системного
> набора сущностей базы данных и метаописания объектов базы данных"

К сожалению, пока такой структуры нет.

> в контексте неизменной базовой функциональности приложения - как Вы его
> себе представляете.

Ну вот если взять, например, схемку в Power Designer, то из его внутреннего формата можно (с разной степенью достоверности) сгеренировать базу данных для довольно большого количества СУБД. Базовые системные объекты должны предоставлять не меньшие возможности в плане описания объектов базы данных (т. е. собственно генератор и словарь конкретной базы данных - не самое главное; важно не потерять существенные детали).

> Как я понимаю это д.б. универсальная структура (ядро системы) в БД и базовый
> функционал на уровне данных БД, позволяющий реализовать с его помощью
> большую часть функциональности стандартных задач учета (и возм. доругих -
> кому что надо), + расширяемый и дополняемый.

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