Похоже, тема иссякла, поскольку все правы ...
2 Игорь. Вы тоже, само собой, правы. Я хотел бы обратить внимание на сказнную выше фразу (правда, она приведена в скобках, поэтому ее могли не заметить):
"...допускаю, что не для всех случаев жизни она (концепция) может сгодиться, но для встреченных мной на практике вполне подходит". Я занимаюсь автоматизацией учета - бухгалтерского, оперативного, управленческого. Для решения этих задач данная концепция очень даже подходит. Для решения задач АСУТП - увы, не годится. И для многих других тоже не годится. Я не пытался найти философский камень.

2Genady. Вы тоже все правильно поняли. За одним ну очень небольшим нюансом:
>надстройка над реляционной схемой данных, которую он пытается решить средствами самой реляционной СУБД (что по моему ему не очень удается, поскольку он оговорился, что для нормальной реализации, клиента все равно трогать приходится).
Да, пока система не доделана, это приходится делать. Но в до конца доделанной системе в этом нет необходимости. Если интерфейс унифицированный для каждого вида макрообъекта(состав панели инструментов, единообразный подход в построении экранных форм макрообъектов одного вида), и в таблицах метаданных хранятся параметры отображения на экране (размеры, положение на форме, цвет шрифта, и т.д.), то визуализация макрообъекта на клиенте производится с помощью динамического формирования экземпляра соответствующего класса.

Расплачиваться приходится всегда и за все. Время загрузки формы, конечно, увеличивается. Только большооо-ооой триггер к этому отношения не имеет. Этот триггер пересчитывает псевдорекурисвным алгоритмом права доступа ко всем объектам при всех ситуациях, которые могут повлиять на права доступа (добавление/удаление ролей, изменение членства в ролях, изменение прав доступа к объектам ролей и т.п.)