OberonCore

И с этим можно согласиться... однако интересно, какой же подход вносит позитивное в картину

Вы применяли Пролог практически – я правильно Вас понял. Но ушли от конкретного вопроса: Почему Пролог мало применяется в базах данных?

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

С моей точки зрения, позитивным может быть подход, основанный на семантическом моделировании. Кратко суть этого подхода можно выразить следующим образом.
1. Стараемся понять суть системы (не отдельные задачи, не структуру, не свойства...);
2. Исходя из сути системы, делается декомпозиция уровней. Это позволяет наделить каждый уровень смыслом, не вступая в противоречие с сутью системы;
3. Далее моделируются (с помощью инструментальных средств) структуры уровней на основе... (здравого) смысла;
4. Реализуем полученные модели;
5. Пошагово развиваем каждый уровень.

Замечания
а) Работа по моделированию, проектированию и реализации уровней может/должна выполняться параллельно для всех уровней. Если, исходя из смысла, межуровневые интерфейсы были (п. 2) правильно смоделированы и спроектированы, то пересечений в разработке уровней быть (принципиально) не должно. Это одно из самых важных следствий, которое влияет на скорость и качество разработки в целом.
б) Можно сказать, что смысл дает ту минимальную модель, с которой необходимо начинать реализацию. Если из этой модели убрать хотя бы один элемент, то она... теряет смысл... буквально... С другой стороны, наращивать эту модель новыми функциями и структурами (п. 5) можно (бесконечно) долго, если эти функции и структуры не противоречат смыслу (обычно, развитие связано с вариабельностью/полиморфизмом и детализацией).
в) В конечном итоге, формируется понимание того, что систему нужно не писать, но собирать (конструировать)... что позволяет сделать процесс создания системы непрерывным на каждой стадии и на каждом уровне.

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

Ну, пусть так:)

К.Томпсон(не последний программист в мире IT:)), пришедший на работу с Вашей многоуровневой архитектурой системы, будет через неделю уволен, как бездарь.

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

Разработку(развитие) архитектуры снизу-вверх представляю следующим образом.

Возьмем MVC, т.к. ВВ наиболее соответствует ей. Model, View и Controller могут быть написаны не только на разных языках, но и на разных платформах.

Выбираем интерфейс и унифицируем его.

Разбиваем цель(выделить компоненты) на подзадачи, направление реализации которых принципиального значения не имеет(?).

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

--- Выделил.

Проблема в том, что придумать и унифицировать интерфейс вообще, в отрыве от задачи, невозможно. Если интерфейс уже есть, удачный и достаточно общий, значит, он уже возникал у кого-то при разработке задач "сверху" - и просто был обобщён. Гораздо больше мертворожденных интерфейсов, которые были спроектированы просто так, только "снизу" - библиотеки, каркасы с большими начальными замыслами, но не выжившие на практике.

Разработку нужно вести одновременно и "снизу" в том смысле, что опираться на объективно имеющуюся инфраструктуру (которая дана и не может быть изменена в данном проекте, ну разве что выбрана один раз как единое целое) - и надстраивать её, подводя под "ниспадающие ветви".

Это проблема авторов, но не стиля. Вообще-то, я не спорю. Даже могу предложить образное сравнение с p-n переходом, где движение электронов и дырок условность(и проверить себя на знание физики )

Стиль -- это существенная часть автора.

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

Скорее, проекция автора на определенную сферу деятельности, поскольку зависит и от автора, и от сферы деятельности, и от (позиции) наблюдателя ("источника света").

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

А что они пробовали? Не было ни самого интерфейса, ни задач, которые его используют... Даже "мыши" не было... Это родилось где-то внутри, а потом... были найдены формы.

Что такое автор.

Тот, кто придумал и реализовал...

Все уже было. Энгельбарт уже об этом думал и писал...

А что было у Энгельбарта?..