Может ли кто-то привести аргументы в пользу ассоциативного доступа (т.е. доступа с помощью языка запросов) к объектно-ориентированным базам данным по сравнению с основным методом доступа к ним — навигационным? В принципе используется он в реальности или языки типа OQL представляют пока только академический интерес?

Здравствуйте, avpet, Вы писали:

A>Может ли кто-то привести аргументы в пользу ассоциативного доступа (т.е. доступа с помощью языка запросов) к объектно-ориентированным базам данным по сравнению с основным методом доступа к ним — навигационным? В принципе используется он в реальности или языки типа OQL представляют пока только академический интерес?

Насколько я своим умом дошел, полноценный доступ с помощью языка запросов возможен только к тем структурам данных, которые специально предназначены для организации такого доступа. В принципе, использование реляционного языка запросов делает невозможной инкапсуляцию данных, и как следствие — полиморфизм. ИМХО для ООБД лучше подходит метод, подобный службе коммерции в CORBA. Т.е. будет лучше всего, если параллельно с объектной моделью будет существовать более простая реляционная модель, используемая следующим образом:

1) Каждая таблица из реляционной модели однозначно ассоциирована с некоторым абстрактным интерфейсом, а не с конкретным классом объектов (экстентом).
2) Набор полей таблицы определяется набором свойств интерфейса, которые объекты публикуют в этой таблице.
3) Язык запросов позволяет только читать данные из таблиц, и строить по ним представления. Писать в таблицы имеют право только объекты, публикующие в них некоторые свои свойства. Соответственно, никакие "referential integrity", "constraints", и т.п. для реляционного предстваления не так уж и нужны, т.к. они автоматически соблюдаются объектной моделью.
4) Главное: каждый отдельный экземпляр любого класса объектов БД волен самостоятельно решать, когда ему публиковаться в реляционной модели, а когда — нет, и на какое время.
5) Каждая запись таблицы имеет поле OID, для связи с объектом. Соответственно, над результатом SELECT можно производить некоторые манипуляции, активизируя опубликованные объекты и вызывая их методы.

Получается такая себе реляционная "витрина" к объектной модели данных. В качестве способа доступа к ней так и просится язык вроде SQL.

lextasy -> "Re: Языки запросов в объектно-ориентированных СУБД" :

l> Насколько я своим умом дошел, полноценный доступ с помощью языка
l> запросов возможен только к тем структурам данных, которые специально
l> предназначены для организации такого доступа. В принципе,
l> использование реляционного языка запросов делает невозможной
l> инкапсуляцию данных, и как следствие — полиморфизм. ИМХО для ООБД
l> лучше подходит метод, подобный службе коммерции в CORBA. Т.е. будет
l> лучше всего, если параллельно с объектной моделью будет существовать
l> более простая реляционная модель, используемая следующим образом:

l> 1) Каждая таблица из реляционной модели однозначно ассоциирована с
l> некоторым абстрактным интерфейсом, а не с конкретным классом объектов
l> (экстентом).
l> 2) Набор полей таблицы определяется набором свойств интерфейса,
l> которые объекты публикуют в этой таблице.

Фаулер. Шаблон Single Table Inheritence. Не всегда самый лучший. Основные
проблемы возникают, когда разные классы поддерживают один интерфейс и при
доставании данных нужно выбрать правильный

l> 3) Язык запросов позволяет только читать данные из таблиц, и строить
l> по ним представления. Писать в таблицы имеют право только объекты,
l> публикующие в них некоторые свои свойства. Соответственно, никакие
l> "referential integrity", "constraints", и т.п. для реляционного
l> предстваления не так уж и нужны, т.к. они автоматически соблюдаются
l> объектной моделью.

Фаулер. Service Layer.

l> 4) Главное: каждый отдельный экземпляр любого класса объектов БД
l> волен самостоятельно решать, когда ему публиковаться в реляционной
l> модели, а когда — нет, и на какое время.
l> 5) Каждая запись таблицы имеет поле OID, для связи с объектом.
l> Соответственно, над результатом SELECT можно производить некоторые
l> манипуляции, активизируя опубликованные объекты и вызывая их методы.

Фаулер. Identify Field. Это я все кому, есть разные пути нажить себе
гемморой

l> Получается такая себе реляционная "витрина" к объектной модели
l> данных. В качестве способа доступа к ней так и просится язык вроде
l> SQL.

Зачем? imho достаточно грамотно спроектированной библиотеки.

Yury Kopyl aka hrg | http://id.totem.ru | [TEAM Nemiroff борет]

Здравствуйте, avpet, Вы писали:

A>Может ли кто-то привести аргументы в пользу ассоциативного доступа (т.е. доступа с помощью языка запросов) к объектно-ориентированным базам данным по сравнению с основным методом доступа к ним — навигационным? В принципе используется он в реальности или языки типа OQL представляют пока только академический интерес?


Можно посмотреть WMI и ее язык запросов. Там свой язык, типа, SQL. От последнего отличается в основном наличием возможности делать запросы по ассоциациям.

Здравствуйте, lextasy, Вы писали:

L>Здравствуйте, avpet, Вы писали:

A>>Может ли кто-то привести аргументы в пользу ассоциативного доступа (т.е. доступа с помощью языка запросов) к объектно-ориентированным базам данным по сравнению с основным методом доступа к ним — навигационным? В принципе используется он в реальности или языки типа OQL представляют пока только академический интерес?

L>Насколько я своим умом дошел, полноценный доступ с помощью языка запросов возможен только к тем структурам данных, которые специально предназначены для организации такого доступа. В принципе, использование реляционного языка запросов делает невозможной инкапсуляцию данных, и как следствие — полиморфизм. ИМХО для ООБД лучше подходит метод, подобный службе коммерции в CORBA. Т.е. будет лучше всего, если параллельно с объектной моделью будет существовать более простая реляционная модель...

Т.е., насколько я понимаю, в силу того, что объектно-ориентированная модель слабо формализована (она скорее прдоставляет удобный механизм хранения и управления данными в приложениях, написанных с использованием объектно-ориентированных языков), и конкретную модель данных определяет предметная область, в которой будет использоваться СУБД, то жизнеспособный универсальный язык запросов для ООСУБД по типу создать невозможно; возможно лишь использование неких специализированных языков, работающих с более высокоуровневыми моделями данных — реляционными и др.

Здравствуйте, avpet, Вы писали:

A>Т.е., насколько я понимаю, в силу того, что объектно-ориентированная модель слабо формализована (она скорее прдоставляет удобный механизм хранения и управления данными в приложениях, написанных с использованием объектно-ориентированных языков), и конкретную модель данных определяет предметная область, в которой будет использоваться СУБД, то жизнеспособный универсальный язык запросов для ООСУБД по типу создать невозможно; возможно лишь использование неких специализированных языков, работающих с более высокоуровневыми моделями данных — реляционными и др.

Абсолютно точно.

Здравствуйте, hrg, Вы писали:

hrg>Фаулер. Шаблон Single Table Inheritence. Не всегда самый лучший. Основные
hrg>проблемы возникают, когда разные классы поддерживают один интерфейс и при
hrg>доставании данных нужно выбрать правильный

Ну и выбросить нафиг надо такой интерфейс, для ипользования которого нужно знать, каким именно классом он реализован.
И вообще, я про наследование ничего не говорил, не так ли? А если нет никакого наследования, то и Single Table Inheritence тут ни к селу, ни к городу.

hrg>Фаулер. Service Layer.
Читаем у Фаулера: "Слой служб определяет границы приложения и множество операций, предоставляемых им для интерфейсных клиентских слоев кода. Он инкапсулирует бизнес-логику приложения, управляет транзакциями и координирует реакции на действия."
По моему, речь не шла об изоляции объектной БД при помощи какого-то промежуточного слоя. Речь шла о внедрении в ООБД языка реляционных запросов, как метода выборки множеств объектов, удовлетворяющих заданным критериям.

hrg>Фаулер. Identify Field. Это я все кому, есть разные пути нажить себе
hrg>гемморой
Не знаю, причем тут Identify Field, но геморрой похоже догадываюсь откуда берется. Инкапсулировать объектную БД за реляционным фасадом — это то же самое, что продать ящик водки, а выручку пробухать.

hrg>Зачем? imho достаточно грамотно спроектированной библиотеки.
Мне пока тоже достаточно. Но если люди интересуются вопросом, значит это им все-таки нужно. Да и службу коммерции в CORBA неспроста, наверное, ввели...

PS.
Касательно Фаулера. Странно как-то на него ссылаться, когда речь идет об ООСУБД. Он вроде эту тему затронул только один раз — дескать, бывают такие маньяки, которые их используют, но я, дескать, к ним не отношусь.

Здравствуйте, avpet, Вы писали:

A>Может ли кто-то привести аргументы в пользу ассоциативного доступа (т.е. доступа с помощью языка запросов) к объектно-ориентированным базам данным по сравнению с основным методом доступа к ним — навигационным? В принципе используется он в реальности или языки типа OQL представляют пока только академический интерес?

Вопрос очень интересен. С одной стороны, RDBMS выиграли битву с сетевыми и иерархическими СУБД еще до появления ООП. И распространенное объяснение их успеха — именно поддержка ad-hoc queries. Отсутствие поддержки навигационных запросов оказалось преимуществом.
С другой стороны, академичность языков типа OQL и OCL пока что остается фактом. С OQL все понятно — ребята, которые его изобретали, сделали две ошибки:
Во-первых, они легким росчерком пера внесли в него фичи, реализация которых оказалась практически невозможной. Разработчики ODBMS потратили десять лет с появления OQL на то, чтобы научиться выполнять хотя бы часть OQL-запросов с приемлемой производительностью.
Во-вторых, они отказались от стандартизации языка семантики методов, решив что язык общего назначения подойдет гораздо лучше. Таким образом, они заложили пропасть между OO и DB прямо в стандарт.

Таким образом, в 2004 году у нас нет ни одной коммерческой полной реализации ODMG OQL. Поэтому делать выводы о его востребованности, вроде как, неправомерно.

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

foreach(IMyObject o in param1)
{
  if(o.IsAvailable  // вирутальное свойство
        && o.CanAccept(param2) // виртуальный булевый метод с параметром
        && o[param3]>param4) // виртуальный индексер
    result.Add(o);
}

и высокой производительностью приложения:

select * from MyObject -- ...

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

lextasy -> "Re[3]: Языки запросов в объектно-ориентированных СУБД" :

hrg>> Фаулер. Шаблон Single Table Inheritence. Не всегда самый лучший.
hrg>> Основные проблемы возникают, когда разные классы поддерживают один
hrg>> интерфейс и при доставании данных нужно выбрать правильный

l> Ну и выбросить нафиг надо такой интерфейс, для ипользования которого
l> нужно знать, каким именно классом он реализован.
l> И вообще, я про наследование ничего не говорил, не так ли? А если нет
l> никакого наследования, то и Single Table Inheritence тут ни к селу,
l> ни к городу.

Ну уговорил Но одна таблица — один класс подходит только для простейших
случаев

hrg>> Фаулер. Service Layer.
l> Читаем у Фаулера: "Слой служб определяет границы приложения и
l> множество операций, предоставляемых им для интерфейсных клиентских
l> слоев кода. Он инкапсулирует бизнес-логику приложения, управляет
l> транзакциями и координирует реакции на действия."
l> По моему, речь не шла об изоляции объектной БД при помощи
l> какого-то промежуточного слоя. Речь шла о внедрении в ООБД языка
l> реляционных запросов, как метода выборки множеств объектов,
l> удовлетворяющих заданным критериям.

А разве ООБД язык — не изоляция? Приложение только знает, что этот объект —
персистентный и ему пофигу, как он будет сохраняться — с транзакциями или
без. И куда.

hrg>> Зачем? imho достаточно грамотно спроектированной библиотеки.
l> Мне пока тоже достаточно. Но если люди интересуются вопросом, значит
l> это им все-таки нужно. Да и службу коммерции в CORBA неспроста,
l> наверное, ввели...

Хз.. с CORBA не работал. Но наверное не зря

l> PS.
l> Касательно Фаулера. Странно как-то на него ссылаться, когда речь идет
l> об ООСУБД. Он вроде эту тему затронул только один раз — дескать,
l> бывают такие маньяки, которые их используют, но я, дескать, к ним не
l> отношусь.

Тем не менее — он показад проблемы и подходы к их решению. Тема ООСУБД очень
интересная.

Yury Kopyl aka hrg | http://id.totem.ru | Гордость мешает доходам!

Здравствуйте, hrg, Вы писали:

hrg>Ну уговорил Но одна таблица — один класс подходит только для простейших
hrg>случаев
Этого должно быть достаточно. Для более сложных случаев есть объектная модель — на то она и ООДБ.

hrg>А разве ООБД язык — не изоляция? Приложение только знает, что этот объект -
hrg>персистентный и ему пофигу, как он будет сохраняться — с транзакциями или
hrg>без. И куда.
ООБД не нуждается ни в какой дополнительной изоляции, или надо менять поставщика ООСУБД (а может, проектировщика БД).
А вот шлюз интеграции со всякими GUI-движками с намертво зашитой в них зависимостью от ADO.Net, ODBC и т.п. — явно не помешает.

hrg>Тем не менее — он показад проблемы и подходы к их решению. Тема ООСУБД очень
hrg>интересная.
Фаулер таки показал проблемы реляционных БД. Похоже, к объектным БД у него врожденная немотивированная аллергия . Хотя то, что он предлагает — это и есть эрзац-ООСУБД.

Здравствуйте, Sinclair, Вы писали:

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

Полноценный язык предикатов давно существует в GemStone Smalltalk. Там запросы записываются точно так же, как реализуется протокол сообщений работы с коллекциями. Клиенский код может работать либо с проксями объектов в базе, либо может быть прозрачно перенесен на сервер и выполняться там в точности как хранимая процедура.
Революция, к сожалению, это совершило только в отдельно взятых компаниях типа JP Morgan.

--

Владимир.

Здравствуйте, _vovin, Вы писали:
_>Полноценный язык предикатов давно существует в GemStone Smalltalk. Там запросы записываются точно так же, как реализуется протокол сообщений работы с коллекциями. Клиенский код может работать либо с проксями объектов в базе, либо может быть прозрачно перенесен на сервер и выполняться там в точности как хранимая процедура.
_>Революция, к сожалению, это совершило только в отдельно взятых компаниях типа JP Morgan.
А что, эти замечательные предикаты смогут там выполняться с использованием индексов? Я так понял, что GemStone этого не умеет. Таким образом, масштабируемость приложений на его базе сильно ограничена. Я не прав?

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, _vovin, Вы писали:
_>>Полноценный язык предикатов давно существует в GemStone Smalltalk. Там запросы записываются точно так же, как реализуется протокол сообщений работы с коллекциями. Клиенский код может работать либо с проксями объектов в базе, либо может быть прозрачно перенесен на сервер и выполняться там в точности как хранимая процедура.
_>>Революция, к сожалению, это совершило только в отдельно взятых компаниях типа JP Morgan.
S>А что, эти замечательные предикаты смогут там выполняться с использованием индексов? Я так понял, что GemStone этого не умеет. Таким образом, масштабируемость приложений на его базе сильно ограничена. Я не прав?

С использованием.
Для RDBMS входным языком является SQL с текстовым синтаксисом, а для GemStone объект-замыкание с байт-кодом. Конечно не все предикаты кладутся на индексы, но в целом по возможностям соблюдается паритет с RDBMS. Ну а по возможностям навигации, само собой, вне конкуренции.

--

Владимир.

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, _vovin, Вы писали:
_>>Полноценный язык предикатов давно существует в GemStone Smalltalk. Там запросы записываются точно так же, как реализуется протокол сообщений работы с коллекциями. Клиенский код может работать либо с проксями объектов в базе, либо может быть прозрачно перенесен на сервер и выполняться там в точности как хранимая процедура.
_>>Революция, к сожалению, это совершило только в отдельно взятых компаниях типа JP Morgan.
S>А что, эти замечательные предикаты смогут там выполняться с использованием индексов?
В том числе с использованием кластерных индексов. Что круто на самом деле.

Здравствуйте, Gaperton, Вы писали:
G>В том числе с использованием кластерных индексов. Что круто на самом деле.
Ну что же, пришел черед и для моих работ. Повторно скачал GemStone/S и доку по нему. Доку уже по диагонали просмотрел, собираюсь поставить саму хрень и пощупать. Упоминаний про кластерность индексов пока не увидел, равно как и упоминаний про возможность оптимизировать полиморфные запросы. В примерах рассматриваются исключительно термы с полями (instance variable). Ох, чувствую я, скоро начну задавать много вопросов более опытным коллегам.

З.Ы. А вообще, похоже. GemStone ближе всех подошли к тому, что собственно надо программерам. GemStone.NET вообще бы не оставил конкурентам никакого шанса.

ООБД и РСУБД настолько имеют ИМХО настолько разные цели, что трудно очень их сравнивать и пытаться перенести понятия из мира РСУБД в мир ООБД.

Вкратце.

1)РСУБД изначально РАЗДЕЛЯЮТ данные и обрабатывающие их программы. И не надо ругать РСУБД за отсутсвие инкапсуляции, не было такой цели у РСУБД никогда и не будет. В этом большая сила РСУБД с точки зрения живучести данных, так как важные данные спокойно переживают устаревающие программы и существуют вооще независимо.
2)ООБД изначально ОБЪЕДИНЯЮТ данные и обрабатывающие их программы, а значит, завязаны на язык 3го поколения, на котором пишутся объекты.
3)Под РСУБД подведена строгая (реляционная)теория
4)Что такое ООБД — не совсем ясно, строго говоря. База данных, хранящая свойства объектов ? База данных, хранящая объекты и дающая доступ только к их интерфесам ? Граф объектов ? У каждого разработчика ООБД по этому поводу свое мнение.
5)Язык запросов — это язык 4го поколения, в отличие от языка реализации обхектов, который, как правило, 3го поколения. Связать эти вещи бывает непросто.

Советы.
Не пытайтейсь одинаково осмысливать РСУБД, сетевые базы, иерархические базы и ООБД. ООБД отличаются диаметрально, т.к. работают не с данными по сути, а с поведением объектов.
Лучше не пытайтесь применить язык запросов в ООБД. Хлопот не оберетесь. Пишите старый добрый навигационный код.
Если все-таки хочется язык запросов — сумейте обработать граф объектов и применить к нему XPATH (реально работающая схема на Java)

Иногда скорость работы ООБД может быть и в тысячи раз выше, чем РСУБД. Обратитесь, например, к концепции Prevayler (www.prevayler.org). Строго говоря, это не ООБД, но решение очень элегантное, простое, быстрое.

P.S. Вообще говоря, если последовательно просмотреть 1й, 2й и 3й манифест, можно придти к неутешительному выводу — РСУДБ ушли немного в сторону от реляционной теории, ООБД висят в воздухе, ОРСУБД — каша невообразимая. Нет идеальных решений. Каждое решение нужно продумать, прощупать, прочувствовать и использовать его так, как оно было задумано и для того, для чего оно было предназначено.

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Gaperton, Вы писали:
G>>В том числе с использованием кластерных индексов. Что круто на самом деле.
S>Ну что же, пришел черед и для моих работ. Повторно скачал GemStone/S и доку по нему. Доку уже по диагонали просмотрел, собираюсь поставить саму хрень и пощупать. Упоминаний про кластерность индексов пока не увидел, равно как и упоминаний про возможность оптимизировать полиморфные запросы.

Точно были. Это основное и единственное, что меня интересовало. Так как Gemstone — это смоллток-система с персистентными объектами, то в общих чертах все и так понятно. Остается один вопрос — есть ли кластреный индекс; если есть — производительности должно хватить, так как все равно в диск упремся. Если нет — то засада.

И в доке я это нашел. "Кластер" создается отдельно, объекты которые к нему относятся располагаются на диске подряд. По возможности конечно.

Впрочем, дальше чтения доки дело у меня не пошло — не хватило времени+желания+необходимости. Напишешь впечатления, если разберешься?

Здравствуйте, Gaperton, Вы писали:

G> Остается один вопрос — есть ли кластреный индекс; если есть — производительности должно хватить, так как все равно в диск упремся.
По какому принципу он догадывается, как именно оптимальнее всего "кластеризовать" объекты?
Ведь кластеризация — это штука такая, с одинаковым успехом может как поднять производительность, так и просадить.

Здравствуйте, Merle, Вы писали:
M>По какому принципу он догадывается, как именно оптимальнее всего "кластеризовать" объекты?
M>Ведь кластеризация — это штука такая, с одинаковым успехом может как поднять производительность, так и просадить.
Там все явно задается. По дефолту, скорее всего, он оптимизирует сканы по коллекциям — т.е. тупо кладет "записи" одну за другой.

Здравствуйте, Gaperton, Вы писали:
G>Точно были. Это основное и единственное, что меня интересовало. Так как Gemstone — это смоллток-система с персистентными объектами, то в общих чертах все и так понятно. Остается один вопрос — есть ли кластреный индекс; если есть — производительности должно хватить, так как все равно в диск упремся. Если нет — то засада.

G>И в доке я это нашел. "Кластер" создается отдельно, объекты которые к нему относятся располагаются на диске подряд. По возможности конечно.
Создается у меня впечатление, что ты путаешь кластер и кластерный индекс. Кластеры в ODBMS используются для оптимизации навигационных запросов, чтобы "близкие" объекты располагались по возможности на одной странице. А кластерный индекс означает совместное расположение записей с близким значеним ключа, и пригоден для оптимизации range-seek запросов.
G>Впрочем, дальше чтения доки дело у меня не пошло — не хватило времени+желания+необходимости. Напишешь впечатления, если разберешься?
Обязательно напишу. Пока что впечатления сугубо негативные:
— инсталлер сработал со второго раза, до перезагрузки упорно рассказывал мне про нехватку ресурсов подсистеме Win16. Ага, а в Requirements написано не ниже Win2000.
— при запуске он выдает на экран путь к логу. При этом на самом деле пишет лог в совсем другое место. Я полчаса потратил только на то, чтобы понять, почему он не взлетает:
— дело в том, что в поставке идет временная лицензия, истекшая в июне. В форуме по суппорту — 2 (!) ответа за все время его существования. Мэйллист, правда, имеет более богатую историю, но он приватный. Я отправил запрос на подписку, жду ответа.

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