KAMIS 2000 - метаописания хранятся в БД. Аналогично свой генератор отчетов работающий по метаописанию (сбор данных) + RTF шаблон загруженный в БД.

Для людей занимающихся настройкой, сделаны простейшие формы, которые начинались от просто "табличке" созданной wizardom, но на протяжении жизни усложнялись.

Весь метаязык, простейшие формулы (когда нужны IF'и) и свой парсер + вроде выполнения кусочков формул передачей его в SELECT'ы. Простейшие - т.е. десятки символов максимум.

Был компонент - генерация HTML-каталогов, где был свой язык. Внедрение данных и кода в HTML + интерпретатор + IF, FOR, переменные и так далее. Типа JSP (его еще в то время не было). Предполагалось, что его смогут использовать заказчики, но для них и это оказалось очень сложно. Хорошо если цвет фона, буковок в HTML найдут и смогут кастомизировать ))).

Для инсталяции - сделан инсталятор (вот там уже простейший текстовый конфиг ))), банальное уникальное имя/код/название_схемы_в_ БД + несколько галочек, какие компоненты для него требуются + положенный dump Oracle). Вся необходимая настроечная информация - фактически содержится в ИКОНКЕ запуска. Путь к установленному Forms'у, путь к директорию с программой, строка соединения с БД. Все остальное (включая актуальный код приложения для обновления) - в БД.

Для формирования обновлений (и ведения БД, своего рода репозиторий версий) - в какой-то момент сделана форма, генератор Update'ов. Сами update - просто bat'ник + sql скрипты (код и файлы необходимые для клиента тоже хранится в БД и обновляются через БД)

Экранные формы (FMB,FMX) строятся системой в момент первого запуска клиентского места (или если клиентское место увидело, что нужно обновится), аналогично обновляются остальные клиентские файлы (PLL, DLL, EXE и т.д.)

и так далее.

по ситуации на начало 2000-х годов

Oracle Utilities Customer Care and Billing

Более переусложненной системы я не видел.

Метаописания в БД, которые артифакт-генератором преобразуются в анотации и код Java ))), для компиляции которых требуется Eclipse со специальными плагинами, компилируется в class'ы и XML пакуется в JAR и деплоится; аннотации преобразуются в XML, которые подгружаются при загрузке приложения и управляют маппингом Java объекты - Json - JScript

Это еще не говоря о Copy Book'ах. Я наивно думал, что код Copy Book'ов сделан автоматически генератором кода. Нифига! Там ошибки! Его писали вручную. Нафига ? Почему было не сделать генератор кода Copy Book'ов по элементарному метаописанию. Манильцев много - напишут.

В общем, п....ц. Зато Hibernate используют )))) JavaScript формирует JSON, который по настроечным XML преврашается в XML с данными, который приход в CC&B объект-сервис, который отображает это на Hibernate объект, который (в некоторых случаях) через Copy Book'и передается в Cobol, который выполняет запись/чтение в БД. При этом тексты запросов хранятся и в БД и в виде Cobol приложения.

Я предлагал отправить меня в командировку в Лос-Анжелес с оплатой ночных клубов за счет фирмы, найти там их архитектора (компания Oracle имя архитектора и его секс предпочтения в тайне не хранила) и популярно объяснить ему, что половина всей этой хренотени в системе даром не нужна. Но начальство оплатить поездку отказалось ))).

В общем, если бы не SPL WG (сейчас Oracle), безработность в Маниле была бы повыше )))

Oracle e-Business Suite - конфиги и справочники также в БД. Возможность документированно добавлять свои модули и отчеты.

Порядок прохождения документов и утверждений задается настройкой в БД + Oracle Workflow.

То же замечательный пример, когда попытка создать специализированное средство, можно признать неудачным. Oracle Workflow - попытка рисовать процессы.... Ну я не видел ни одного разработчика, который бы это освоил. При возможности решить задачу через Pl/SQL и через Workflow, всегда выбирали PL/SQL.

Oracle Scripting - сам не сталкивался,. По описаниям людей, тихий ужас. Продукт наверное сам по себе и ничего, но осмысленности в нем мало. Т.к. программисту проще задачу решить на PL/SQL, а консультант/аналитик/пользователь все равно не освоит.

1C - я так понимаю, в БД + текст приложения конфигурации

На реальном проекте обучал студентов рисовать отчеты для OeBS на XML Publisher'е.

Через пару месяцев, от заказчика был резонный вопрос "почему высококвалифицированные специалисты консалтера (со ставкой 500$ в день), отчеты делают значительно (в 2-а раза) медленнее, чем вчерашние студенты за совершенно другую зарплату"

Тот случай, когда термин овер квалифаев замечательно характеризует работу

В принципе, требуется тот же био-робот, взял ТЗ, скопи-пастил в комментарии во view, для каждого поля в отчете, через интерфейс OeBS посмотрел источник данных (запрос), скопипастил, написал LEFT OUTER JOIN между табличками.

Код SQL конечно студенты порождали специфический.... Но кого это волнует при SMP-сервере от IBM за полляма долларов? Разумеется когда в запросе оказывалось что табличка раз десять сама с собой соединяется LEFT OUTER JOIN - оно переставало работать. Тогда обращались с вопросом, где ошибка и как исправить )))

Но при всем при этом, я 100% уверен, что данные студенты ни одного отчета, способного "повесить сервер" не написали. А даже думаю, что отчетов работающих больше пары секунд у них так же не было.

Наблюдал картину на другом проекте, когда мега аналитики, создавали мега-ТЗ, который воплощали достаточно квалифицированные программисты и мега админы бегали вокруг продакшен сервера (наверное даже еще более дорогого) и пытались быстро эти отчеты килят, что бы сервер не лег. А что еще может получится, если одного взгляда на ТЗ достаточно, что бы посочувствовать программисту, который будет пытаться это воплотить на PL/SQL )))