Максим НПредставьте тот же самый Hibernate, но завязанный на конкретную базу. Система генерирует не голые insert/update/delet'ы/select'ы, а разумные процедуры и функции на стороне БД на ее родном языке, используя все ее фичы, а на стороне клиента java (например) классы обертки для этих процедур/функций.
Т.о. субд'эшники получают полную свободу действий в своей любимой БД, а клиентские программисты избавляются от ненавистного им sql в своем коде, оперируя как и раньше классами, объектами и методами, не задумываясь о базе.
Существует ли такое и насколько востребовано? Может кто то использовал или пытался воплотить?
В такой архитектуре просто нет смысла, и заниматься этим можно только от безысходности на фоне использования "реляционных систем".

Если на уровне БД не поддерживаются основные принципы БД, в том числе, такие как:
1. В БД что-то должно отражать факт существования объекта независимо от его свойств.
2. Модель данных должна быть одна и та же на концептуальном и логическом уровнях.
3. Результатом запроса должна быть часть БД со всей присущей БД семантикой.
4. Содержательные метаданные (в рамках МД, удовлетворяющей пункту 2) должны поддерживаться на уровне БД.
то Вы "попадаете" на банальный маппинг по всем трем аспектам МД.

А если поддерживаются, то нет никакой необходимости в предлагаемой Вами архитектуре:)

Очевидно, что в популярных SQL-системах ни один из принципов БД не поддерживается и даже теоретически не может поддерживаться. Вероятно, и по этим причинам тоже SQL бесполезен для подавляющего большинства приложений - это известный доказанный факт. Системы, не использующие SQL, и удовлетворяющие принципам БД, быстрее разрабатываются, быстрее работают, и трудоемкость их сопровождения и развития намного меньше.

Разумеется, разработчики "реляционных приложений" делают для себя периодически нечто подобное тому, что Вы описали:) Или EAV:)

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

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

vadiminfoБредятинаУдобнее игнорировать принципы БД, ...
Можно, отметить, что мешочки и "бяда с ключами" тоже хорошо подходят для игнорирования. Впрочем, и другие выдумки ЧАЛа типа объектный навигатор и "крах РМД" обладают, скорее всего, повышенной игнорностью.
:) Да нет, дорогой. У меня все всегда по существу. Я Вам доходчиво про принципы объясняю, чтобы Вы могли темы по существу обсуждать. Эту, как видно, не можете. Потому что не усвоили предыдущий материал. А стиль, в котором на sql.ru принято обижаться на свое незнание или непонимание меня уже давно не удивляет. Так что, продолжайте:)

egorychБредятинаЕсли на уровне БД не поддерживаются основные принципы БД, в том числе, такие как:
1. В БД что-то должно отражать факт существования объекта независимо от его свойств.
2. Модель данных должна быть одна и та же на концептуальном и логическом уровнях.
3. Результатом запроса должна быть часть БД со всей присущей БД семантикой.
4. Содержательные метаданные (в рамках МД, удовлетворяющей пункту 2) должны поддерживаться на уровне БД.
то Вы "попадаете" на банальный маппинг по всем трем аспектам МД.

А если поддерживаются, то нет никакой необходимости в предлагаемой Вами архитектуре:)давайте попробуем перевести ваши рассуждения в практическую плоскость. Может быть, вы назовёте наконец СУБД, удовлетворяющую этим принципам?
А я все время в практической плоскости.
1. Вы "попадаете" на банальный маппинг? Попадаете.
2. Вы не согласны с принципами БД (не мной сформулированными)? Поясните.
3. Система этим принципам не удовлетворяющая СУБД не является, поскольку для управления данными приходится использовать, фактически, еще одну систему.
Таким образом, ЛЮБАЯ СУБД УДОВЛЕТВОРЯЕТ ЭТИМ ПРИНЦИПАМ.
Автор темы рассуждает о некой СУБД, которая получится, когда к "реляционной системе" приделают нечто. И я напоминаю, что эта СУБД должна удовлетворять базовым принципам БД. Вполне возможно, что она и будет им удовлетворять:) Но ее часть - "реляционная система" - не может им удовлетворять в принципе:)
Так же я напоминаю, что для разработки СУБД существует, к моему искреннему сожалению, только одна среда (технология), которая позволяет любому небольшому коллективу грамотных специалистов (и даже одному грамотному специалисту) выполнить эту, казалось бы сложную, разработку за вполне приемлемые сроки, сравнимые со сроками создания среднего приложения в "реляционной системе". То есть, автор темы предлагает значительно более трудоемкий путь создания СУБД.
И что же Вы видите не практичного в моем первом сообщении?