Часть 2.
Далее мое ИМХО, по поводу всей идеи совмещения концепций ОО и реляционных баз данных.
Если уж подходить к реализации хранения объектов, то лучше уж что-нибудь
в духе иерархических баз данных использовать. Объект о1 содержит объекты о11, о12, о13, в
свою очередь объект о11 содержит 100 объектов о111 и т.д. С точки зрения программирования объектов
это более естественно.
Но это все семечки. Уж как данные объекта хранить можно придумать и реализовать. Но вот зачем это надо?
Вот это вопрос серьезнее (потому как из области общей философии и прочей мета-физики ;-).
Если посмотреть на современное состояние дел в области ОО-программирования, то там четко прослеживается
курс к созданию дизайна систем на основе паттернов проектирования и схожих с ними концепций. А что они
ставят во главу угла - тезис о том, что класс (а следовательно и объект) должен определяться своими
обязанностями. А это не что иное как набор методов, через которые с ним взаимодействуют другие классы
(объекты). И инкапсулируются не просто данные внутри объекта, но и сам тип объекта (через механизм
абстрактных классов и интерфейсы).
Ведь изначально какую проблему пытались решить с помощью ОО-методологий?
Проблему разработки хорошо сопровождаемых, легко модифицируемых систем. Именно в этом направлении
были направлены "смелые опыты буржуйских ученых". А проблема хранения больших объемов данных, их быстрый
поиск и обработка - это несколько иное направление деятельности (причем инструменты решения проблем в этой области
разрабатываются, в том числе, и с применением ОО-разработки). И если уж мы хотим хранить информацию, то зачем
привязываться к объектам. Они нужны для создания контекста, в котором реализуются механизмы
для хранения данных, но не факт, что сами данные надо хранить в объектах. Тогда все станет на свои
места и не надо будет мучительно размышлять, как же приспособить несовместимые вещи друг к другу.
Кстати, если взять большинство современных реализаций механизмов доступа к базам данных, то они подтверждают
мой тезис (будь то dataset или recordset - все это механизмы создания контекста хранения данных, но
информация, которую они хранят не имеет отношения к собственным рабочим данным этих объектов). Вот если мы
хотим смоделировать поведение чего-либо (будь то поставщик, накладная, ТМЦ), то объект будет как раз
кстати. У него есть методы, используя которые мы можем им управлять. Он может взаимодействовать с другими
объектами в системе. Все это динамическое поведение. И ему присущи данные о текущем состоянии объекта в системе, которые
существуют, пока существует объект. А данные, которые ему соответствуют как моделируемой сущности
(ФИО, номер, дата, наименование и т.д.), и которые должны хранится постоянно, как раз-таки и получаем из базы
данных. Но эти данные принадлежат этому конкретному объекту только на время его текущей жизни. Объект, конечно же,
может их изменить, но может и не изменить. А в следующем запуске они будут принадлежать другому объекту.
Основная мысль в том, что объекты интересны в разрезе их поведения и все классические характеристики ОО-подхода
(полиморфизм, наследование, про инкапсуляцию не только данных, я уже говорил), подчеркивают именно
эту сторону объектов. Ну зачем, например, наследование при хранении данных в базе. Избавиться от дублирования
информации - так это ерунда. И так механизмов достаточно (НФ рулят ;-). А объекты подклассов
и так хранят данные и свои и базовых классов. Ни полиморфизм, ни наследование реально в базе данных
смысла не несут. По крайней мере, применение идеологии, лежащей в их основе, затруднено.
По той же причине не имеет смысла хранить методы объектов (или грубо говоря их поведение). Это и так реализовано в коде
приложения, а механизмы привязки алгоритмов обработки к самим данным должны быть реализованы уж никак
не подобным образом.
Может быть поэтому так буксует разработка ООСУБД, что пытаются совместить в одном флаконе объектов
две совершенно разные концепции?

Получилось несколько пессимистично. Ну да ничего, главное вера в свои силы ;-).
Мне кажется, если уж задумываться о совмещении ОО-подхода и реляционных баз данных, то нужно начинать со стороны
СУБД. Там уже есть язык описания и структуры данных и выполнения над данными манипуляций (sql форева ;-).
С хранением данных тоже проблем не возникает (таблицы). В качестве интерфейсов - виды. Остается только добавить
реализацию некоторых базовых концепций (можно и на внешних поцедурах) и полный вперед. Начинаем ОО-разработку
на расширенном sql ;-). Кстати, все к этому и идет (все дружно посмотрели в сторону Редмонда и выудили
из подсознания загадочное слово Yukon ;-). Хе-хе, это уже так, оффтопиком.

2 ппп
Да я его и не жду ;-)
Мне и так хватает инструментов.
Это относилось к теме топика. Предлагается делать логику работы с объектами вне СУБД. Вот в конце последнего своего поста я и предложил рассмотреть вопрос о переносе ее на СУБД (что Вы и предлагаете ;-)

2 c127

ИМХО не поэтому, а потому, что разработчики ООСУБД не представляют, что они делают. Интуитивно вроде все просто и понятно, но вот оказывается этого недостаточно, нужно записать формализацию.
&&
Так этим же автор топика и занимается.

После прочтения доступной мне информации по созданию ООСУБД, сложилось впечатление, что разработчики оных стараются максимально интегрироваться в существующие объектно-ориентированные языки. Тогда достигается желаемая монолитность проекта (работаем на языке высокого уровня, который неявно сам обрабатывает задачи хранения данных). Насколько я понял - это практический результат исследований в этой области. Этим же для меня, как для разработчика будет привлекательна ООСУБД по сравнению с РСУБД. Поэтому, я рассматривал статью автора с этой точки зрения. Согласен, что если взглянуть на проблему с другой стороны (на сервере РСУБД крутиться внутренняя логика, коротая поддерживает ОО-подход), то статья в этом плане будет самое то. Формализация - это конечно же хорошо и нужно. Но реализация такого механизма - нетривиальная задача. Для ее воплощения потребуются значительные средства. А получим ли мы желаемый результат? Ведь монолитности в проекте все равно не будет. Опять останется аналог sql для базы и С++, Java, etc. для всего остального. Опять нужны люди кодирующие для базы и люди кодирующие для всего остального. ИМХО, именно этого и хотелось бы избежать.

2 funikovyuri

Надо для создания единой системной архитектуры с единой методологией - ООАП

Но ведь методологию можно и сейчас подобную использовать. И практически все авторы, которые пишут книги по проектированию архитектуры проекта используют классы, хранящие бизнес-информацию, в общей классовой структуре. Они в контексте создаются, обрабатываются и сохраняются. Тут проблем нет. И реализовать логику поддержки персистентности можно множеством достаточно несложных способов. Проблема возникает, когда объемы данных возрастают, сложность обработки увеличивается... все начинает работать жутко медленно (естественно по сравнению с РСУБД). Проблема возникает, когда приходится создавать параллельно для поддержки классов, описывающих бизнес-информацию, структуры в реляционной БД (и логику ввода/вывода), а время поджимает и людей не хватает. Чтобы ускорить и упростить процесс и хотелось иметь СУБД, которая органично вписывалась бы в существующий язык ОО-программирования и позволяла скрыть детали, оставив высокую производительность.
Поэтому, кстати, я и говорил, что мне не кажется необходимым заботиться о реализации артефактов ОО-программирования (наследование, полиморфизм, etc) в СУБД. Достаточно того, что она будет хранить информацию, которая соответствовала бы предметной области и к которой легко (способами, прозрачными для разработчика) осуществлялся бы доступ из объектов классов. В принципе, эту задачу мы в своем проекте и пытались решить. И с этой же задачей статья автора, мне кажется, достаточно коррелирует.