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

Обсуждение.... признаться, наиболее деликатное, что я могу сказать по этому поводу - "ничего интересного". Более точно на эту тему высказался некто Кнышев:

Пришейте к подушке куриную голову. Готово? А теперь попробуйте обьяснитъ, зачем вы это сделали.

NafОсновная идея сделать SQL более модульным и гибким в разработке больших проектов.
Замечательно. Раз так, значит, Вы можете назвать серию ситуаций, в который SQL проявляет немодульность и негибкость, и назвать для каждой из них существенно превосходящее решение. Так?

NafРезультатов пока нет. Одна теория пока
Это, уж простите, не теория. Это ближе к еще одной цитате:

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

MasterZivВо-вторых, БД и инкапсуляция - вообще вещи несовместимые.
Крайне странное рассуждение. Just for example, updateable view - идеальный пример инкапсуляции в БД.

Более того, можно отметить тот факт, что из тринадцати правил Кодда шесть посвящены именно обеспечению инкапсуляции.

MasterZivИнкапсуляция же призвана служить тому, чтобы вместо структурированных данных имелся лишь абстрактный BLOB с его адресом и размером.
Это, простите, какая-то глупость. Все равно что сказать "инкапсуляция же призвана служить тому, чтобы вместо vector<int> имелся лишь абстрактный void* с размером".

MasterZivв БД применить инкапсуляцию, БД НЕ СМОЖЕТ РАБОТАТЬ С ДАННЫМИ. Потому что
она должна знать их структуру. Так что в объектных БД от инкапсуляции отказываются, вернее сказать, разрешают ее ослаблять.
Мне так представляется, Вы игнорируете тот факт, что понятие "инкапсуляция" относительно, и делаете его чем-то абсолютным.

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

Таким образом, несмотря на то, что "А довольно много знает о Б" никакого нарушения инкапсуляции не происходит. Теперь осталось соотнести объект Б например с таблицей в реляционной БД. Этот объект Б публикует свой интерфейс (колонки, методы запроса и модификации), и прячет весьма нетривиальную реализацию (которая учитывает, что например date колонки хранятся иначе, чем varchar, а blob - так и вовсе в другом месте). Объект Б пользователю часто недоступен (нет грантов). Вместо него гранты даются на объект А (view или procedure), который отгораживает "детали реализации" вторым слоем.

Как оно в объектных БД - не в курсе, но подозреваю, и для них Ваше высказывание черезчур резко.

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

MasterZivХде ? В БД ?
Да.

MasterZivДанные внутри БД, внутри таблицы инкапсулировать
нельзя.
Можно.

MasterZivПотому что СУБД должна с ними работать как-то.
Еще один странный аргумент. Полностью аналогичный "данные внутри программы инкапсулировать нельзя, поскольку компилятор должен с ними как-то работать".

Да, таблицы не инкапсулированы от СУБД, а внутренности классов не инкапсулированы от компилятора. Что не мешает тому и другому быть инкапсулированным от "пользователя" - где под пользователем понимается программный модуль, желающий получить сервис.

MasterZivИзолировать один класс от другого с помощью тех же процедур - можно (и даже иногда нужно), но далеко не всегда эффективно.
Эффективность - отдельный вопрос. Точно так же неэффективно использовать get/set методы для доступа к переменной.

Дмитрий16Я сейчас работаю над наложением объектной структуры на классическом MS SQL
И придете к той же классической декларации о несовместимости :) Не готов к подробному обсуждению, но в "множестве мелких запросов" также нет ровно ничего хорошего.

Нужно просто понимать, что "выборка" - это отдельный, цельный объект, не имеющий "один к одному" ни к объектам в СУБД, ни к объектам на клиенте.