U-geneЭклектично :) Я когда-то давным-давно использовал plain С и не как не мог понять, что же все носятся с С++. "Не все ли равно?" думал я что класс, что структура - те же яйца, только в профиль". Оказалось - не те. В общем, НВы стали смотреть на языковые конструкции, я предлагаю посмотреть на то. что этими конструкциями реализуется.

0) ничего не исчезает - по-прежнему можно использовать обычные для SQL табличные структутры.

А что в этом хорошего? Объектно-реляционный франкенштейн получается.


U-gene1) Появляются классы. При этом мы исходим из идеи, что объект по своей сложности сравним с реляционной БД. Состояние объекта описывается множеством значений отношений (точнее - не более сложных, чем значения отношений). Если раньше мы хранили данные о , например, накладной в двух таблицах, то теперь можно описать класс "накладная", и вместо того, что бы делать JOIN, использовать точечную нотацию.

У Вас объект как электрон у Ленина - неисчерпаем. :-) Идея с точечной нотацией правильная, но вот только по хорошему это должен быть полноценный запрос, а точка - контекстно зависимой операцией.


U-gene(На самом деле этот пункт - "состояние объекта есть множество значений отношений" - позволяет применить к таким сложным объектам трансформации, основанные исключительно на РМД. Например, запросы к данным описанным в терминах сложных структур - это "замаскированные" JOINы, выборки, проекции и тд, (то есть традиционные реляционные операции ) выполняемые согласованно с операцией переименования атрибутов.)

С моей точки зрения у Вас в кучу свалены вопросы хранения и прикладной обработки персистентных данных. ОБД должна работать даже с приложением написанном на ассемблере без применения ООП.


U-gene2) Появляется возможность использования ссылок между классами. Опять таки, вместо того, что бы JOINить можно использовать ссылочные конструкции. При этом, несмотря на кажущуюся направленность ссылок, запросы к данным работают в обеих "направлениях". (тут выше про это написано).

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


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

Это в целом понятно. Здесь например проявляется то, что семантики такого значения как NULL уже не достаточно.


U-gene5) Методы инкапсулированы в классе и полиморфны. Допускается групповой вызов методов.

Опять же класс как единица хранения может иметь совсем другой функционал чем класс в ООП прикладной программе.


U-geneВы говорите, что нет модели. Вам шашечки или ехать? Я сознательно не употребляю термин "модель" применительно к объектам. Мне это не нравится. Но смотрите. Структура объекта определяется правилом "множество значений, не более сложных, чем отношения". Я могу описывать сложные объекты, использовать ссылки, у меня реализованы инкапсуляция, тотальный(и компоненты и метода) полиморфизм, даже множественное наследование. Мне не нужны экстенты, мне не нужны итераторы, я обхожусь без обязательного описания обратных ссылок. В общем, модель (не люблю это слово, когда про объекты) есть. Просто она такая простая, что вы несколько раз мимо прошли и не заметили. Конечно, с ODMG3.0 где модель на ...цати листах описывается, она не сравниться. Там, только коллекций 8 штук , если не ошибаюсь. Моя модель маленькая, но достаточая, В ODMG модель сложная, а у меня она очень простая - при большей мощности.

В ОМД достаточной одной коллекции. Объект считаю определен неправильно. Но если Ваши конкретные задачи решаются, то и слава богу.

U-geneПро OQL. (кстати - он вроде не загнулся ) Но, опять таки, давайте начнем не с конструкций, а с идеи. OQL создавался для программистами для программистов. Я не буду говорить, хорошо это или плохо, но полноценно работать с ODMG объектами можно только из языка програмирования. Кстати, насколько я понимаю, OQL не был ни разу полноценно реализован. Только какие то кусочки. Это был(есть?) такой красивый прожект.

Что касается схожести. Ну да, раз есть иерархические конструкции, то грех не воспользоваться точечной нотацией. Но в остальном.... ODMG требует явного определения обратных ссылок. ODMG требует эсктенты, ODMG содержит очень много близких конструкций, что делает модель излишне сложной. Про полиморфные виды я вообще нигде не слышал. Запросы ODMG могут выполняться только в языковой среде. Результат запросов ODMG неоднороден по структуре (могут вернуть ссылку, структура, литерал) - в общем они предназначены для дальнейшей обработки в языковой среде.

А здесь запросы выполняются сервером as is (как любой SQL запрос), возвращают данные о состоянии объектов, существующих на стороне сервера. Результат - всегда отношение(таблица). То есть языковые конструкции местами может и схожи, но концепция и идея в целом вообще другая.

Собственно неудача OQL по моему как раз и предопределена была тем что не смог народ разделить объектный подход к программированию от объектного подхода к хранению данных.

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

U-geneТочно так же я могу спросить "А что в этом плохого? Объектно реляционный рай для разработчика получается.

Я понимаю что скажем программисту в общем случае удобно иметь возможность писать программу одновременно и на С# и на ассемблере. Это даже можно назвать раем. Однако понятно и то что большинство задач можно решить используя только С#. Соотвественно объектная парадигма должна позволять решать большинство задач не прибегая к реляционной модели данных как таковой.


U-gene
Про неисчерпаемость. Формула "Объект = реляционная БД" действительно делает возможной рекурсивную вложенность с обеих сторон . Если с левой стороны мы говорим, что объект состоит из других объектов, то с правой стороны, мы можем говорить о подмножестве реляционной БД, которое (в силу замкнутости реляционных операций) тоже есть реляцонная БД. Этот вопрос, кстати, обсуждается во многих источниках

Моё мнение просто состоит в том что модель данных должна быть достаточно легко понятной и логичной. Системы основанные именно на таких моделях могут привлечь пользователей к их применению. Я не большой ученый и статью Вашу я просмотрел по диагонали. Поэтому мне например трудно понять что такое "подмножество реляционной БД".


U-gene
Не понял. Что значит "полноценный запрос"? Что значит "контексто-зависимая операция"? Давайте примеры, тогда и разберемся, что такое - "по хорошему".

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


U-gene С моей точки зрения, речь идет не о "персистентных данных", а о "данных о персистенных объектах", которые подразумевают не только значения свойств, но и инкапсулированный функционал, позволяющий изменять состояние и описывающий зависисмости между этими персистентыми объектами. Я уже устал объяснять, что это не "объекты для приложения", а "самипосебе объекты".

Я собственно о том что скажем и в приложении и в БД используются описания одного и того же объекта. Но эти описания исходят из разных целей, они разные и в общем случае имеют разный "инкапсулированный функционал", а могут и не иметь "инкапсулированного функционала".

U-geneКстати, эта Ваша фраза содержит внутреннее противоречие. Если мы собираемся "работать с объектами на ассемблере", то объекты (экземпляры класса, инкапсулирующие состояние и поведение) , где то как то должны ...мммм ..... образоваться... или быть..., то есть эти самые состояние и поведение где должны быть уже "свалены в кучу". Вот я и предлагаю ровно эту возможность с наименьшими трудозатратами.

У описаний объекта в БД и в приложении может быть совершенно разное поведение, в то время как у реального прототипа может не быть никакого поведения. То что в БД является объектом, в приложении может им и не быть. И наоборот. Распространенная ошибка состоит в том что считается что ОБД это хранилище ООП объектов.

U-gene Вот это то самый случай, когда я начинаю сомневаться в Вашем понимании предмета. Речь идет о том, что в ODMG стандарте двухстронние ссылки - это нетривиальная штука. Если мы описываем ссылку из класса А на класс Б, то в классе Б надо описать "встречную" ссылку на класс А. У меня же такую "встречную" ссылку описывать не нужно. То есть мои языковые расширения имеют ту же мощность при меньшей сложности.
В связи с этим, мысль про "направлений гораздо больше" проясните пожалуйста. Можно идти по ссылкам, можно идти против ссылок, но, видимо, Вы хотите идти куда то вбок.Я прав?

Я о том что могут быть десятки классов объекты которых связаны графом произвольного вида в том числе связями типа N:N.

U-gene Как идея о недостаточности NULL связана с поздним связыванием и неявным UNION - это я вообще не понял. Но, раз тон не негативный - выяснять не буду. :)

Смысл в том что если Вы объединяете объекты с разным набором свойств, то кроме NULL - "значение не задано" по хорошему должно появиться ещё одно спецзначение с семантикой "свойство не задано".


U-gene Единица хранения -все же объект. Но не в этом дело. Я не понимаю, почему Вы все время пытаетесь отделить хранение от обработки? У меня объект - единица хранения, с инкапсулированным функционалом ("сампосебе объект"). Он не храниться - он активно существует на сервере. Никакого другой функционал (как единице существования) ему не нужен.

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


U-gene "Ну почему?" _{(с) Карлсон} Классы есть , структура объектов сложная, они персистентые, состояние и поведение инкапсулировано, есть множественное наследование, есть полиморфизм и по состоянию и по поведению, можно задавать ключи, ad-hoc запросы к данным какие хошь, что то там еще.... :) В общем - непонятные капризы.

Вы в основном про ООП объекты. Я про объекты как элементы модели данных.


U-geneДа. :) Делаю в СУБД чего хочу. Могу использовать табличные структуры, могу описывать данные как объекты. Могу классы использовать как домены. Могу в одном запросе выдернуть данные из таблиц и из классов. Еще чего то с классами могу. Могу.

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

U-geneОпять какие-то приложения, загрузчики, объектные модели, двоичные коды. Всё свалено в кучу.

Видимо это Ваше " статью Вашу я просмотрел по диагонали " распространяется и на мои посты. Например
Serg99Программный объект существует после запуска приложения. До этого он существует мертвым телом в виде описания ... идальше целый абзац это Вы зачем написали? Нет у меня мертвых тел и приложений. О чем Вы?

Я о Вашем "объект активно существует на сервере". Выключите питание сервера и задумайтесь где теперь существует объект и в каком виде.

U-geneSerg99Смысл в том что если Вы объединяете объекты с разным набором свойств, то кроме NULL - "значение не задано" по хорошему должно появиться ещё одно спецзначение с семантикой "свойство не задано" Это Вы откуда взяли? Я не применяю операцию UNION к объектам с разным набором свойств. О чем Вы?

Я о Вашем "Когда мы делаем запрос к классу, у которого есть наследники...UNION...". Если у Вас все наследники имеют одинаковый набор свойств, то непонятно зачем такая иерархия наследования.


U-geneSerg99Распространенная ошибка состоит в том что считается что ОБД это хранилище ООП объектов. У кого ошибка? Я не хочу вдаваться в смысл фразы, но о каком "хранилище" Вы говорите? Вы, видимо опять о приложениях и загрузчиках? Так у меня этого нет. О чем Вы?

О том что ООП объекты моделируют реальные объекты в приложении, а объекты модели данных БД обслуживают персистентное описание предметной области в общем случае независимо от приложений.

U-geneSerg99Я о том что могут быть десятки классов объекты которых связаны графом произвольного вида в том числе связями типа N:N. И что? У меня впечатления, Что Ваша цель в споре - показаться умным. Я говорю.о фактической двунаправленности ссылок,Вы вваливете мне фразу "Что касается направлений, то мы живем не на линии, а в трехмерном мире (то есть направлений может быть гораздо больше).". Скажите, какое отношение имеет возможное количество ссылок к их направленности? Зачем Вы ввалили эту фразу?

Долго объяснять :-).

U-gene Serg99 Давайте остановимся на Вашем признании " статью Вашу я просмотрел по диагонали " . Это очень хорошо объясняет все мои недоумения.

Давайте :-).


U-geneЧто касается смысла Выших высказываний....здесь в начале Дедушка написал " Авторы подобных изысканий всегда неявно подразумевают, что всё и вся нужно моделировать объектами. ИМХО это не так ." я с ним полностью согласен. По мне объекты - это, что может быть , а не должно быть .
Мы пока не встречали задач которые нельзя было бы моделировать объектами. Даже тесты TPC. Сам процесс познания имеет "объектный" характер. Таблицы же это скорее удобный способ представления данных в процессе их обработки.