Re: Языки запросов в объектно-ориентированных СУБД
От: Sinclair Россия https://github.com/evilguest/
Дата: 07.09.04 03:41
Оценка: 20 (3)
Здравствуйте, 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 -- ...

Однако конкретных примеров необходимости именно полиморфных запросов я привести прямо сейчас не смогу. Возможно, мы настолько привыкли обходиться без таких возможностей, что сразу проектируем приложения с учетом их отсутствия.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re: Языки запросов в объектно-ориентированных СУБД
От: lextasy Украина www.mira-tech.com.ua
Дата: 06.09.04 14:14
Оценка: 8 (2)
Здравствуйте, avpet, Вы писали:

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


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

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

Получается такая себе реляционная "витрина" к объектной модели данных. В качестве способа доступа к ней так и просится язык вроде SQL.
Re: Языки запросов в объектно-ориентированных СУБД
От: borisman2 Киргизия  
Дата: 14.09.04 19:02
Оценка: 18 (1)
ООБД и РСУБД настолько имеют ИМХО настолько разные цели, что трудно очень их сравнивать и пытаться перенести понятия из мира РСУБД в мир ООБД.

Вкратце.

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

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

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

P.S. Вообще говоря, если последовательно просмотреть 1й, 2й и 3й манифест, можно придти к неутешительному выводу — РСУДБ ушли немного в сторону от реляционной теории, ООБД висят в воздухе, ОРСУБД — каша невообразимая. Нет идеальных решений. Каждое решение нужно продумать, прощупать, прочувствовать и использовать его так, как оно было задумано и для того, для чего оно было предназначено.
Re[2]: Языки запросов в объектно-ориентированных СУБД
От: avpet  
Дата: 06.09.04 15:06
Оценка: 6 (1)
Здравствуйте, lextasy, Вы писали:

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


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


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


Т.е., насколько я понимаю, в силу того, что объектно-ориентированная модель слабо формализована (она скорее прдоставляет удобный механизм хранения и управления данными в приложениях, написанных с использованием объектно-ориентированных языков), и конкретную модель данных определяет предметная область, в которой будет использоваться СУБД, то жизнеспособный универсальный язык запросов для ООСУБД по типу создать невозможно; возможно лишь использование неких специализированных языков, работающих с более высокоуровневыми моделями данных — реляционными и др.
Re[2]: Языки запросов в объектно-ориентированных СУБД
От: Sinclair Россия https://github.com/evilguest/
Дата: 15.09.04 06:21
Оценка: +1
Здравствуйте, borisman2, Вы писали:
B>Советы.
B>Не пытайтейсь одинаково осмысливать РСУБД, сетевые базы, иерархические базы и ООБД. ООБД отличаются диаметрально, т.к. работают не с данными по сути, а с поведением объектов.
B>Лучше не пытайтесь применить язык запросов в ООБД. Хлопот не оберетесь. Пишите старый добрый навигационный код.
Именно это и сдерживает их применение. Старый добрый навигационный код надо отлизывать руками для достижения приемлемой производительности. Это означает, что вопросы производительности дают "отдачу" по рукам архитектору сельнее, чем противотанковое ружье. А ответы на эти вопросы зачастую невозможно получить до развертывания системы. В итоге мы имеем единичные success stories, где архитектору удалось угадать особенности применения и заложить удачное решение. А РДБМС благодаря декларативности позволяют дотюнить решение уже на этапе эксплуатации без изменений в клиентском или бизнес-коде.
... << RSDN@Home 1.1.4 @@subversion >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[8]: Языки запросов в объектно-ориентированных СУБД
От: Sinclair Россия https://github.com/evilguest/
Дата: 17.09.04 06:16
Оценка: +1
Здравствуйте, lextasy, Вы писали:

L>Но это не мешает ему все-таки предпочитать Java/C# + ORM + RDBMS. Потому и говорю, что его аллергия ничем не мотивирована в техническом плане. Скорее всего проблема в том, что заказчики не доверяют технологии ООСУБД; их слух ласкает слово Oracle.

Скорее всего проблема в том, что OODBMS в настоящее время настолько далеки от возможностей RDBMS по обработке действительно больших объемов данных, что никто не хочет платить лишнего. Как только речь заходит о настоящем OLTP, вперед выдвигается тройка Oracle+MS SQL+DB2. Никакими ODBMS тут даже не пахнет.
... << RSDN@Home 1.1.4 @@subversion >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Языки запросов в объектно-ориентированных СУБД
От: avpet  
Дата: 06.09.04 12:06
Оценка:
Может ли кто-то привести аргументы в пользу ассоциативного доступа (т.е. доступа с помощью языка запросов) к объектно-ориентированным базам данным по сравнению с основным методом доступа к ним — навигационным? В принципе используется он в реальности или языки типа OQL представляют пока только академический интерес?

06.09.04 16:40: Перенесено модератором из 'Базы данных' — _MarlboroMan_
Re[2]: Языки запросов в объектно-ориентированных СУБД
От: hrg Россия  
Дата: 06.09.04 14:26
Оценка:
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 борет]
Posted via RSDN NNTP Server 1.9 beta
Re: Языки запросов в объектно-ориентированных СУБД
От: StanislavK Великобритания  
Дата: 06.09.04 14:44
Оценка:
Здравствуйте, avpet, Вы писали:

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



Можно посмотреть WMI и ее язык запросов. Там свой язык, типа, SQL. От последнего отличается в основном наличием возможности делать запросы по ассоциациям.
Re[3]: Языки запросов в объектно-ориентированных СУБД
От: lextasy Украина www.mira-tech.com.ua
Дата: 06.09.04 17:05
Оценка:
Здравствуйте, avpet, Вы писали:

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


Абсолютно точно.
Re[3]: Языки запросов в объектно-ориентированных СУБД
От: lextasy Украина www.mira-tech.com.ua
Дата: 06.09.04 17:36
Оценка:
Здравствуйте, hrg, Вы писали:

hrg>Фаулер. Шаблон Single Table Inheritence. Не всегда самый лучший. Основные

hrg>проблемы возникают, когда разные классы поддерживают один интерфейс и при
hrg>доставании данных нужно выбрать правильный

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

hrg>Фаулер. Service Layer.

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

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

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

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

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

PS.
Касательно Фаулера. Странно как-то на него ссылаться, когда речь идет об ООСУБД. Он вроде эту тему затронул только один раз — дескать, бывают такие маньяки, которые их используют, но я, дескать, к ним не отношусь.
Re[4]: Языки запросов в объектно-ориентированных СУБД
От: hrg Россия  
Дата: 07.09.04 07:14
Оценка:
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 | Гордость мешает доходам!
Posted via RSDN NNTP Server 1.9 beta
Re[5]: Языки запросов в объектно-ориентированных СУБД
От: lextasy Украина www.mira-tech.com.ua
Дата: 07.09.04 11:03
Оценка:
Здравствуйте, hrg, Вы писали:

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

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

hrg>А разве ООБД язык — не изоляция? Приложение только знает, что этот объект -

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

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

hrg>интересная.
Фаулер таки показал проблемы реляционных БД. Похоже, к объектным БД у него врожденная немотивированная аллергия . Хотя то, что он предлагает — это и есть эрзац-ООСУБД.
Re[2]: Языки запросов в объектно-ориентированных СУБД
От: _vovin http://www.pragmatic-architect.com
Дата: 07.09.04 11:20
Оценка:
Здравствуйте, Sinclair, Вы писали:

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


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

--

Владимир.
Re[3]: Языки запросов в объектно-ориентированных СУБД
От: Sinclair Россия https://github.com/evilguest/
Дата: 07.09.04 15:16
Оценка:
Здравствуйте, _vovin, Вы писали:
_>Полноценный язык предикатов давно существует в GemStone Smalltalk. Там запросы записываются точно так же, как реализуется протокол сообщений работы с коллекциями. Клиенский код может работать либо с проксями объектов в базе, либо может быть прозрачно перенесен на сервер и выполняться там в точности как хранимая процедура.
_>Революция, к сожалению, это совершило только в отдельно взятых компаниях типа JP Morgan.
А что, эти замечательные предикаты смогут там выполняться с использованием индексов? Я так понял, что GemStone этого не умеет. Таким образом, масштабируемость приложений на его базе сильно ограничена. Я не прав?
... << RSDN@Home 1.1.4 beta 1 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[4]: Языки запросов в объектно-ориентированных СУБД
От: _vovin http://www.pragmatic-architect.com
Дата: 07.09.04 16:21
Оценка:
Здравствуйте, Sinclair, Вы писали:

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

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

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

--

Владимир.
Re[4]: Языки запросов в объектно-ориентированных СУБД
От: Gaperton http://gaperton.livejournal.com
Дата: 07.09.04 16:45
Оценка:
Здравствуйте, Sinclair, Вы писали:

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

_>>Полноценный язык предикатов давно существует в GemStone Smalltalk. Там запросы записываются точно так же, как реализуется протокол сообщений работы с коллекциями. Клиенский код может работать либо с проксями объектов в базе, либо может быть прозрачно перенесен на сервер и выполняться там в точности как хранимая процедура.
_>>Революция, к сожалению, это совершило только в отдельно взятых компаниях типа JP Morgan.
S>А что, эти замечательные предикаты смогут там выполняться с использованием индексов?
В том числе с использованием кластерных индексов. Что круто на самом деле.
Re[5]: Языки запросов в объектно-ориентированных СУБД
От: Sinclair Россия https://github.com/evilguest/
Дата: 11.09.04 07:44
Оценка:
Здравствуйте, Gaperton, Вы писали:
G>В том числе с использованием кластерных индексов. Что круто на самом деле.
Ну что же, пришел черед и для моих работ. Повторно скачал GemStone/S и доку по нему. Доку уже по диагонали просмотрел, собираюсь поставить саму хрень и пощупать. Упоминаний про кластерность индексов пока не увидел, равно как и упоминаний про возможность оптимизировать полиморфные запросы. В примерах рассматриваются исключительно термы с полями (instance variable). Ох, чувствую я, скоро начну задавать много вопросов более опытным коллегам.

З.Ы. А вообще, похоже. GemStone ближе всех подошли к тому, что собственно надо программерам. GemStone.NET вообще бы не оставил конкурентам никакого шанса.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[6]: Языки запросов в объектно-ориентированных СУБД
От: Gaperton http://gaperton.livejournal.com
Дата: 14.09.04 19:14
Оценка:
Здравствуйте, Sinclair, Вы писали:

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

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

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

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

Впрочем, дальше чтения доки дело у меня не пошло — не хватило времени+желания+необходимости. Напишешь впечатления, если разберешься?
Re[7]: Языки запросов в объектно-ориентированных СУБД
От: Merle Австрия http://rsdn.ru
Дата: 14.09.04 20:34
Оценка:
Здравствуйте, Gaperton, Вы писали:

G> Остается один вопрос — есть ли кластреный индекс; если есть — производительности должно хватить, так как все равно в диск упремся.

По какому принципу он догадывается, как именно оптимальнее всего "кластеризовать" объекты?
Ведь кластеризация — это штука такая, с одинаковым успехом может как поднять производительность, так и просадить.
... [RSDN@Home 1.1.4 revision 142]
Мы уже победили, просто это еще не так заметно...
Re[8]: Языки запросов в объектно-ориентированных СУБД
От: Sinclair Россия https://github.com/evilguest/
Дата: 15.09.04 05:56
Оценка:
Здравствуйте, Merle, Вы писали:
M>По какому принципу он догадывается, как именно оптимальнее всего "кластеризовать" объекты?
M>Ведь кластеризация — это штука такая, с одинаковым успехом может как поднять производительность, так и просадить.
Там все явно задается. По дефолту, скорее всего, он оптимизирует сканы по коллекциям — т.е. тупо кладет "записи" одну за другой.
... << RSDN@Home 1.1.4 @@subversion >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[7]: Языки запросов в объектно-ориентированных СУБД
От: Sinclair Россия https://github.com/evilguest/
Дата: 15.09.04 05:56
Оценка:
Здравствуйте, Gaperton, Вы писали:
G>Точно были. Это основное и единственное, что меня интересовало. Так как Gemstone — это смоллток-система с персистентными объектами, то в общих чертах все и так понятно. Остается один вопрос — есть ли кластреный индекс; если есть — производительности должно хватить, так как все равно в диск упремся. Если нет — то засада.

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

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

В общем, Gemstone не выглядят ребятами, которым нужны клиенты. Им, похоже, и без нас хорошо.
Ладно, посмотрим в полный рост, когда наконец удастся поднять этого зверя.
... << RSDN@Home 1.1.4 @@subversion >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[8]: Языки запросов в объектно-ориентированных СУБД
От: Gaperton http://gaperton.livejournal.com
Дата: 15.09.04 09:18
Оценка:
Здравствуйте, Sinclair, Вы писали:

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

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

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

S>Создается у меня впечатление, что ты путаешь кластер и кластерный индекс. Кластеры в ODBMS используются для оптимизации навигационных запросов, чтобы "близкие" объекты располагались по возможности на одной странице. А кластерный индекс означает совместное расположение записей с близким значеним ключа, и пригоден для оптимизации range-seek запросов.

Под "кластерным индексом" в данном случае я понимаю возможность контроллировать физический порядок записей на диске. Естественно, "близкие" объекты должны лежать в одной странице на диске, чтобы получить мало-мальски приемлемую производительность (но не навигационных запросов! А именно range-seek. Если навигационные запросы распределены случайно, то нам вобщем все равно, сгруппированы близкие объекты или нет). А вот если близкие страницы идут по возможности подряд, то последовательная выборка будет раз минимум в 10 быстрее. Потому как за один оборот диска все прочтется. Ну, в лучшем случае .

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

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

S>Обязательно напишу. Пока что впечатления сугубо негативные:
S>...
S>В общем, Gemstone не выглядят ребятами, которым нужны клиенты. Им, похоже, и без нас хорошо.
S>Ладно, посмотрим в полный рост, когда наконец удастся поднять этого зверя.
Твоя решимость довести дело до победного конца внушает уважение Ждем!
Re[8]: Языки запросов в объектно-ориентированных СУБД
От: Gaperton http://gaperton.livejournal.com
Дата: 15.09.04 09:19
Оценка:
Здравствуйте, Merle, Вы писали:

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


G>> Остается один вопрос — есть ли кластреный индекс; если есть — производительности должно хватить, так как все равно в диск упремся.

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

Ты явно создаешь кластер, и явно относишь объекты к экземпляру кластера.
Re[6]: Языки запросов в объектно-ориентированных СУБД
От: serg_mo  
Дата: 15.09.04 09:33
Оценка:
Здравствуйте, lextasy, Вы писали:

L>Фаулер таки показал проблемы реляционных БД. Похоже, к объектным БД у него врожденная немотивированная аллергия


Ну, не сказал бы, что у него аллергия. Вот, например, его цитата:

"I believe that many of the systems we build today in Java would be better
built in Smalltalk and Gemstone." -- Martin Fowler, JAOO 2003

... << RSDN@Home 1.1.3 stable >>
Re[7]: Языки запросов в объектно-ориентированных СУБД
От: lextasy Украина www.mira-tech.com.ua
Дата: 16.09.04 11:37
Оценка:
Здравствуйте, serg_mo, Вы писали:

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


L>>Фаулер таки показал проблемы реляционных БД. Похоже, к объектным БД у него врожденная немотивированная аллергия


_>Ну, не сказал бы, что у него аллергия. Вот, например, его цитата:


_>

_>"I believe that many of the systems we build today in Java would be better
_>built in Smalltalk and Gemstone." -- Martin Fowler, JAOO 2003


Но это не мешает ему все-таки предпочитать Java/C# + ORM + RDBMS. Потому и говорю, что его аллергия ничем не мотивирована в техническом плане. Скорее всего проблема в том, что заказчики не доверяют технологии ООСУБД; их слух ласкает слово Oracle.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.