> Просто уровень копания разный.

Да нет же, абсолютно одинаковый. ;)

Модель Тенцера - это метамодель. Пусть примитивная, но метамодель. Ваша схема - это тоже метамодель. Сложнее, больше функционала, выше уровень абстракции, - да, но при этом нет качественного перехода. Что происходит: Вы отказываетесь от реляционной модели (т. е. расширяете SQL-2003 (или какой СУБД Вы пользуетесь?) метамодель) в обмен на хм... некоторые дополнительные возможности. Причем, расширяете одноразово, т. е. Ваша дополнительная метамодель никак не связана с метамоделью СУБД. Imho можно отказаться от реляционной модели - но в обмен на радикальное изменение функционала + сохранение возможностей реляционной модели. ;)

> А , вообще, кажется, что все это лишний геморрой.

Но ведь зачем-то Вы эту схему создали (причем, не один вариант)? Вряд ли просто потому, что было немного свободного времени. ;))

> Просто не знаю окупится ли все это

Imho не окупится; скорее эта задача [пока] из разряда теоретических.

> Получается СУБД в СУБД?

Можно сказать и так. По сути - система хранения метаданных + СУБД. В чем фишка такой реализации (если кто-то когда-то до нее доберется, конечно): возможность описания любых (почти любых, - дальше "любых" с той же оговоркой) данных, возможность оперирования данными (причем, разнородными; например, реляционными и xml-подобными) внешних источников, возможность маппинга данных разных источников, дополнительный функционал (например, контроль доступа на разных уровнях), возможность описания данных в разных моделях одновременно и пр. В общем, много чего можно придумать. ;)

Плохо то, что MOF модель (супермодель, метаметамодель) плохо ложится на реляционную структуру: она xml-подобна. К сожалению, я не знаю о заслуживающих внимания реализациях хранения xml файлов в реляционной стрктуре данных (не тупым маппингом, а с использованием xsd-like метамодели).

> Вот минимальная структура с помощью которой можно описать все.

"Все" в смысле все, что отвечает Вашим задачам? Или вообще любую структуру? ;)

> Словарь данных приложения не обязательно со словарем данных СУБД, а в системах практической
> сложности всегда используется свой словарь данных.

Если я правильно Вас понял, любое уважающее себя приложение должно иметь не только собственную модель данных, но и собственную метамодель? ;))

> Один и тот же факт в таблицы можно положить по разному,

Я не увидел принципиальной разницы между описанием того, что Вы назвали фактом, в предложенной Вами структуре и системной. Плохо смотрел?

> imho да, без нее построить настраиваемую систему очень тяжело построить.

Позвольте Вам не поверить.

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

Уважаемый дон понимает разницу между конфигом приложения и метамоделью?

> 2. чтобы интегрироваться не на уровне записей в бд, а на уровне бизнес-объектов

Что такое бизнес-объекты? Что такое не-бизнес-объекты?

> иначе не построить схемы трансформации данных и др.

Я не успеваю следить за полетом Вашей мысли: какие данные куда Вы собрались трансформировать?

> 3. Без метамодели объектов

Что такое объект? Что такое метамодель объектов?

> для обеспечения настраиваемого контроля доступа

Нет. Row-level security в рамках реляционной модели строится на раз-два-три.

> 1. Не верьте (но предоставьте пример АБС (автоматизированной
> банковской системы без метамодели))

Это предложение работы? Не вижу бюджета проекта.

> 2. конфиг строится на основе данных метамодели

;))

> 3. бизнес-объект - сделка, не-бизнес- туева хуча таблиц, ее описывающих

Какая сделка? Это какой-то специфичный объект базы данных? Чем он отличается от обычных объектов?

> 4. Данные собрался трансформировать в форматы сделок (а не таблиц)
> для внешних систем и принимать их (их данные тоже трансформировать)

Упс. Повторю вопрос относительно сделки. Дополню вопросом о формате сделки. Это тоже какой-то специфичный объект?

> 5. ладно, метамодели классов объектов

;) Понятнее не стало. Какие метамодели каких классов каких объектов? Вы вообще о чем говорите?

> 6. row-level нах никому не надо вне привязки к конкретным
> бизнес-объектам:

Из предыдущего текста я понял, что бизнес-объект - это сделка. Я правильно интерпретировал текст: "без привязки к сделкам row-level контроль доступа не имеет смысла"? Если правильно, то Вы ошибаетесь. ;))

> доступ к таблице abc мне не надо запрещать как админу приложения - мне
> надо защищать доступ к атрибуту цена закрытия котировки ЦБ.

Хм... ну, во-первых, доступ к таблице и row-level контроль - это как бы два разных уровня ограничения доступа. ;) Во-вторых, я не вижу ни одной проблемы "защиты доступа к атрибуту цена закрытия котировки ЦБ".

> 1. Как всегда отбазарились вопросами на вопросы

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

> 2. см. п.1, но...

Вы не понимаете очевидной разницы между конфигом и метамоделью.

> 5. лозунг - пример в студию

Какой лозунг? Пример чего?

> 6. пример плиз.

Класс сильно вряд ли имеет метамодель. ;) Модель - да.

Вообще у вас смешались в кучу кони, люди: откуда-то вдруг интерфейсы появились, параметры класса. Что есть параметры класса? Атрибуты? Или очередная непонятная характеристика? Что есть интерфейс? Откуда и какие вдруг возникли проблемы с 12 числом?

> одной метамоделью предметной области

Поподробнее, пожалуйста: что это за метамодель предметной области? И представить себе не мог, что такие существуют.

Ага, кажется, догадался: Вы неправильно понимаете и используете термины "модель" и "метамодель". ;))

> А что можете предложить Вы?!

Непосредственно Вам - пожалуйста, перестаньте путать модель с метамоделью. А вообще о своем предложении я уже писал: метамодель должна быть стандартной.

> Думаю можно описать и хранить любые объекты и отношения.
> Этой структуры должна хватит.

ОК, пусть так. А насколько удобно это будет делать?

Давайте предположим, что мы храним xml файл. Тогда в Вашей структуре данных мы должны: 1. сначала описать соответствующую метамодель, 2. в терминах этой метамодели описать модель, 3. в терминах модели описать файл.

Imho три уровня абстракции в одной структуре данных - многовато. ;)

> Флейм про мета не от разных точек отсчета?

По-видимому, так и есть.

> Так что я насчет метамодели данных я ничего не утверждал и кстати редко
> видел.

Вы писали как-то о MOF (не в этом треде), из чего я сделал вывод, что контекст обсуждения Вам понятен.

ОК, вопросы снимаются, ответы на них очевидны, если Вы говорите о модели, а не о метамодели.

> Теперь надо объяснить,что без нее в серьезных вещах практически никак
> (примеры я уже привел)

Без чего "без нее", уточните, пожалуйста. ;))

> Умение развести флейм - суть поведения на форуме ряда людей.

;) Согласитесь, я меньше всего виноват в том, что Ваша терминология отличается от общепринятой, правда? И абсолютно не виноват в том, что для того, чтобы это выяснить, понадобилась страница обсуждения.

> 2.конфиг без модели предметной области?Все зашить в код?! Ню-ню...

Ага, то есть мы уже о модели говорим. ;) Хорошо.
Зачем "зашить в код"? Храните конфиги отдельно, как и следует это делать.

> 3. 12 - просто для балды число

Да я понял, что от балды. Я не знаю, что у Вас за пупер-мега-приложение, которое не позволяет делать элементарных вещей. Традиционная модель ограничения доступа: интерфейс, объекты бд, row-level. Проще всего на row-level сделать комбинированный доступ: (rwe + acl). Все. Никаких 12 чисел. Ничего запредельного.

Хотите реального контроля доступа - почитайте про контекст безопасности (на примере хотя бы SELinux). Штука интересная, но для практической реализации жутко геморройная.

> 4.пусть параметры класса будут атрибутами

Давайте окончательно определимся: если Вы говорите об объектах бд, то там нет никаких классов. Если используете какую-то другую парадигму, напишите об этом явным образом.

> 5.интерфейс-в смысле междумордия приложения,GUI

Imho два подхода. Самый простой я уже описал выше.

> 6. Предложения по поводу настраиваемового приложения конкретно в
> плане настроек проводок (конфига), контроля доступа, генераторов
> отчетов в "терминах предметной области"

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