Здравствуйте, 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: Языки запросов в объектно-ориентированных СУБД
Здравствуйте, avpet, Вы писали:
A>Может ли кто-то привести аргументы в пользу ассоциативного доступа (т.е. доступа с помощью языка запросов) к объектно-ориентированным базам данным по сравнению с основным методом доступа к ним — навигационным? В принципе используется он в реальности или языки типа OQL представляют пока только академический интерес?
Насколько я своим умом дошел, полноценный доступ с помощью языка запросов возможен только к тем структурам данных, которые специально предназначены для организации такого доступа. В принципе, использование реляционного языка запросов делает невозможной инкапсуляцию данных, и как следствие — полиморфизм. ИМХО для ООБД лучше подходит метод, подобный службе коммерции в CORBA. Т.е. будет лучше всего, если параллельно с объектной моделью будет существовать более простая реляционная модель, используемая следующим образом:
1) Каждая таблица из реляционной модели однозначно ассоциирована с некоторым абстрактным интерфейсом, а не с конкретным классом объектов (экстентом).
2) Набор полей таблицы определяется набором свойств интерфейса, которые объекты публикуют в этой таблице.
3) Язык запросов позволяет только читать данные из таблиц, и строить по ним представления. Писать в таблицы имеют право только объекты, публикующие в них некоторые свои свойства. Соответственно, никакие "referential integrity", "constraints", и т.п. для реляционного предстваления не так уж и нужны, т.к. они автоматически соблюдаются объектной моделью.
4) Главное: каждый отдельный экземпляр любого класса объектов БД волен самостоятельно решать, когда ему публиковаться в реляционной модели, а когда — нет, и на какое время.
5) Каждая запись таблицы имеет поле OID, для связи с объектом. Соответственно, над результатом SELECT можно производить некоторые манипуляции, активизируя опубликованные объекты и вызывая их методы.
Получается такая себе реляционная "витрина" к объектной модели данных. В качестве способа доступа к ней так и просится язык вроде SQL.
Re: Языки запросов в объектно-ориентированных СУБД
ООБД и РСУБД настолько имеют ИМХО настолько разные цели, что трудно очень их сравнивать и пытаться перенести понятия из мира РСУБД в мир ООБД.
Вкратце.
1)РСУБД изначально РАЗДЕЛЯЮТ данные и обрабатывающие их программы. И не надо ругать РСУБД за отсутсвие инкапсуляции, не было такой цели у РСУБД никогда и не будет. В этом большая сила РСУБД с точки зрения живучести данных, так как важные данные спокойно переживают устаревающие программы и существуют вооще независимо.
2)ООБД изначально ОБЪЕДИНЯЮТ данные и обрабатывающие их программы, а значит, завязаны на язык 3го поколения, на котором пишутся объекты.
3)Под РСУБД подведена строгая (реляционная)теория
4)Что такое ООБД — не совсем ясно, строго говоря. База данных, хранящая свойства объектов ? База данных, хранящая объекты и дающая доступ только к их интерфесам ? Граф объектов ? У каждого разработчика ООБД по этому поводу свое мнение.
5)Язык запросов — это язык 4го поколения, в отличие от языка реализации обхектов, который, как правило, 3го поколения. Связать эти вещи бывает непросто.
Советы.
Не пытайтейсь одинаково осмысливать РСУБД, сетевые базы, иерархические базы и ООБД. ООБД отличаются диаметрально, т.к. работают не с данными по сути, а с поведением объектов.
Лучше не пытайтесь применить язык запросов в ООБД. Хлопот не оберетесь. Пишите старый добрый навигационный код.
Если все-таки хочется язык запросов — сумейте обработать граф объектов и применить к нему XPATH (реально работающая схема на Java)
Иногда скорость работы ООБД может быть и в тысячи раз выше, чем РСУБД. Обратитесь, например, к концепции Prevayler (www.prevayler.org). Строго говоря, это не ООБД, но решение очень элегантное, простое, быстрое.
P.S. Вообще говоря, если последовательно просмотреть 1й, 2й и 3й манифест, можно придти к неутешительному выводу — РСУДБ ушли немного в сторону от реляционной теории, ООБД висят в воздухе, ОРСУБД — каша невообразимая. Нет идеальных решений. Каждое решение нужно продумать, прощупать, прочувствовать и использовать его так, как оно было задумано и для того, для чего оно было предназначено.
Re[2]: Языки запросов в объектно-ориентированных СУБД
Здравствуйте, lextasy, Вы писали:
L>Здравствуйте, avpet, Вы писали:
A>>Может ли кто-то привести аргументы в пользу ассоциативного доступа (т.е. доступа с помощью языка запросов) к объектно-ориентированным базам данным по сравнению с основным методом доступа к ним — навигационным? В принципе используется он в реальности или языки типа OQL представляют пока только академический интерес?
L>Насколько я своим умом дошел, полноценный доступ с помощью языка запросов возможен только к тем структурам данных, которые специально предназначены для организации такого доступа. В принципе, использование реляционного языка запросов делает невозможной инкапсуляцию данных, и как следствие — полиморфизм. ИМХО для ООБД лучше подходит метод, подобный службе коммерции в CORBA. Т.е. будет лучше всего, если параллельно с объектной моделью будет существовать более простая реляционная модель...
Т.е., насколько я понимаю, в силу того, что объектно-ориентированная модель слабо формализована (она скорее прдоставляет удобный механизм хранения и управления данными в приложениях, написанных с использованием объектно-ориентированных языков), и конкретную модель данных определяет предметная область, в которой будет использоваться СУБД, то жизнеспособный универсальный язык запросов для ООСУБД по типу создать невозможно; возможно лишь использование неких специализированных языков, работающих с более высокоуровневыми моделями данных — реляционными и др.
Re[2]: Языки запросов в объектно-ориентированных СУБД
Здравствуйте, borisman2, Вы писали: B>Советы. B>Не пытайтейсь одинаково осмысливать РСУБД, сетевые базы, иерархические базы и ООБД. ООБД отличаются диаметрально, т.к. работают не с данными по сути, а с поведением объектов. B>Лучше не пытайтесь применить язык запросов в ООБД. Хлопот не оберетесь. Пишите старый добрый навигационный код.
Именно это и сдерживает их применение. Старый добрый навигационный код надо отлизывать руками для достижения приемлемой производительности. Это означает, что вопросы производительности дают "отдачу" по рукам архитектору сельнее, чем противотанковое ружье. А ответы на эти вопросы зачастую невозможно получить до развертывания системы. В итоге мы имеем единичные success stories, где архитектору удалось угадать особенности применения и заложить удачное решение. А РДБМС благодаря декларативности позволяют дотюнить решение уже на этапе эксплуатации без изменений в клиентском или бизнес-коде.
... << RSDN@Home 1.1.4 @@subversion >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[8]: Языки запросов в объектно-ориентированных СУБД
Здравствуйте, lextasy, Вы писали:
L>Но это не мешает ему все-таки предпочитать Java/C# + ORM + RDBMS. Потому и говорю, что его аллергия ничем не мотивирована в техническом плане. Скорее всего проблема в том, что заказчики не доверяют технологии ООСУБД; их слух ласкает слово Oracle.
Скорее всего проблема в том, что OODBMS в настоящее время настолько далеки от возможностей RDBMS по обработке действительно больших объемов данных, что никто не хочет платить лишнего. Как только речь заходит о настоящем OLTP, вперед выдвигается тройка Oracle+MS SQL+DB2. Никакими ODBMS тут даже не пахнет.
... << RSDN@Home 1.1.4 @@subversion >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Может ли кто-то привести аргументы в пользу ассоциативного доступа (т.е. доступа с помощью языка запросов) к объектно-ориентированным базам данным по сравнению с основным методом доступа к ним — навигационным? В принципе используется он в реальности или языки типа OQL представляют пока только академический интерес?
06.09.04 16:40: Перенесено модератором из 'Базы данных' — _MarlboroMan_
Re[2]: Языки запросов в объектно-ориентированных СУБД
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 достаточно грамотно спроектированной библиотеки.
Здравствуйте, avpet, Вы писали:
A>Может ли кто-то привести аргументы в пользу ассоциативного доступа (т.е. доступа с помощью языка запросов) к объектно-ориентированным базам данным по сравнению с основным методом доступа к ним — навигационным? В принципе используется он в реальности или языки типа OQL представляют пока только академический интерес?
Можно посмотреть WMI и ее язык запросов. Там свой язык, типа, SQL. От последнего отличается в основном наличием возможности делать запросы по ассоциациям.
Re[3]: Языки запросов в объектно-ориентированных СУБД
Здравствуйте, avpet, Вы писали:
A>Т.е., насколько я понимаю, в силу того, что объектно-ориентированная модель слабо формализована (она скорее прдоставляет удобный механизм хранения и управления данными в приложениях, написанных с использованием объектно-ориентированных языков), и конкретную модель данных определяет предметная область, в которой будет использоваться СУБД, то жизнеспособный универсальный язык запросов для ООСУБД по типу создать невозможно; возможно лишь использование неких специализированных языков, работающих с более высокоуровневыми моделями данных — реляционными и др.
Абсолютно точно.
Re[3]: Языки запросов в объектно-ориентированных СУБД
Здравствуйте, 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]: Языки запросов в объектно-ориентированных СУБД
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> отношусь.
Тем не менее — он показад проблемы и подходы к их решению. Тема ООСУБД очень
интересная.
Здравствуйте, hrg, Вы писали:
hrg>Ну уговорил Но одна таблица — один класс подходит только для простейших hrg>случаев
Этого должно быть достаточно. Для более сложных случаев есть объектная модель — на то она и ООДБ.
hrg>А разве ООБД язык — не изоляция? Приложение только знает, что этот объект - hrg>персистентный и ему пофигу, как он будет сохраняться — с транзакциями или hrg>без. И куда.
ООБД не нуждается ни в какой дополнительной изоляции, или надо менять поставщика ООСУБД (а может, проектировщика БД).
А вот шлюз интеграции со всякими GUI-движками с намертво зашитой в них зависимостью от ADO.Net, ODBC и т.п. — явно не помешает.
hrg>Тем не менее — он показад проблемы и подходы к их решению. Тема ООСУБД очень hrg>интересная.
Фаулер таки показал проблемы реляционных БД. Похоже, к объектным БД у него врожденная немотивированная аллергия . Хотя то, что он предлагает — это и есть эрзац-ООСУБД.
Re[2]: Языки запросов в объектно-ориентированных СУБД
Здравствуйте, Sinclair, Вы писали:
S>Интуитивно мне кажется, что поддержка полноценного языка предикативных запросов способна совершить революцию. В настоящее время мы вынуждены выбирать между высокой производительностью программиста:
Полноценный язык предикатов давно существует в GemStone Smalltalk. Там запросы записываются точно так же, как реализуется протокол сообщений работы с коллекциями. Клиенский код может работать либо с проксями объектов в базе, либо может быть прозрачно перенесен на сервер и выполняться там в точности как хранимая процедура.
Революция, к сожалению, это совершило только в отдельно взятых компаниях типа JP Morgan.
--
Владимир.
Re[3]: Языки запросов в объектно-ориентированных СУБД
Здравствуйте, _vovin, Вы писали: _>Полноценный язык предикатов давно существует в GemStone Smalltalk. Там запросы записываются точно так же, как реализуется протокол сообщений работы с коллекциями. Клиенский код может работать либо с проксями объектов в базе, либо может быть прозрачно перенесен на сервер и выполняться там в точности как хранимая процедура. _>Революция, к сожалению, это совершило только в отдельно взятых компаниях типа JP Morgan.
А что, эти замечательные предикаты смогут там выполняться с использованием индексов? Я так понял, что GemStone этого не умеет. Таким образом, масштабируемость приложений на его базе сильно ограничена. Я не прав?
... << RSDN@Home 1.1.4 beta 1 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[4]: Языки запросов в объектно-ориентированных СУБД
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, _vovin, Вы писали: _>>Полноценный язык предикатов давно существует в GemStone Smalltalk. Там запросы записываются точно так же, как реализуется протокол сообщений работы с коллекциями. Клиенский код может работать либо с проксями объектов в базе, либо может быть прозрачно перенесен на сервер и выполняться там в точности как хранимая процедура. _>>Революция, к сожалению, это совершило только в отдельно взятых компаниях типа JP Morgan. S>А что, эти замечательные предикаты смогут там выполняться с использованием индексов? Я так понял, что GemStone этого не умеет. Таким образом, масштабируемость приложений на его базе сильно ограничена. Я не прав?
С использованием.
Для RDBMS входным языком является SQL с текстовым синтаксисом, а для GemStone объект-замыкание с байт-кодом. Конечно не все предикаты кладутся на индексы, но в целом по возможностям соблюдается паритет с RDBMS. Ну а по возможностям навигации, само собой, вне конкуренции.
--
Владимир.
Re[4]: Языки запросов в объектно-ориентированных СУБД
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, _vovin, Вы писали: _>>Полноценный язык предикатов давно существует в GemStone Smalltalk. Там запросы записываются точно так же, как реализуется протокол сообщений работы с коллекциями. Клиенский код может работать либо с проксями объектов в базе, либо может быть прозрачно перенесен на сервер и выполняться там в точности как хранимая процедура. _>>Революция, к сожалению, это совершило только в отдельно взятых компаниях типа JP Morgan. S>А что, эти замечательные предикаты смогут там выполняться с использованием индексов?
В том числе с использованием кластерных индексов. Что круто на самом деле.
Re[5]: Языки запросов в объектно-ориентированных СУБД
Здравствуйте, Gaperton, Вы писали: G>В том числе с использованием кластерных индексов. Что круто на самом деле.
Ну что же, пришел черед и для моих работ. Повторно скачал GemStone/S и доку по нему. Доку уже по диагонали просмотрел, собираюсь поставить саму хрень и пощупать. Упоминаний про кластерность индексов пока не увидел, равно как и упоминаний про возможность оптимизировать полиморфные запросы. В примерах рассматриваются исключительно термы с полями (instance variable). Ох, чувствую я, скоро начну задавать много вопросов более опытным коллегам.
З.Ы. А вообще, похоже. GemStone ближе всех подошли к тому, что собственно надо программерам. GemStone.NET вообще бы не оставил конкурентам никакого шанса.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[6]: Языки запросов в объектно-ориентированных СУБД
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Gaperton, Вы писали: G>>В том числе с использованием кластерных индексов. Что круто на самом деле. S>Ну что же, пришел черед и для моих работ. Повторно скачал GemStone/S и доку по нему. Доку уже по диагонали просмотрел, собираюсь поставить саму хрень и пощупать. Упоминаний про кластерность индексов пока не увидел, равно как и упоминаний про возможность оптимизировать полиморфные запросы.
Точно были. Это основное и единственное, что меня интересовало. Так как Gemstone — это смоллток-система с персистентными объектами, то в общих чертах все и так понятно. Остается один вопрос — есть ли кластреный индекс; если есть — производительности должно хватить, так как все равно в диск упремся. Если нет — то засада.
И в доке я это нашел. "Кластер" создается отдельно, объекты которые к нему относятся располагаются на диске подряд. По возможности конечно.
Впрочем, дальше чтения доки дело у меня не пошло — не хватило времени+желания+необходимости. Напишешь впечатления, если разберешься?
Re[7]: Языки запросов в объектно-ориентированных СУБД
Здравствуйте, Gaperton, Вы писали:
G> Остается один вопрос — есть ли кластреный индекс; если есть — производительности должно хватить, так как все равно в диск упремся.
По какому принципу он догадывается, как именно оптимальнее всего "кластеризовать" объекты?
Ведь кластеризация — это штука такая, с одинаковым успехом может как поднять производительность, так и просадить.
... [RSDN@Home 1.1.4 revision 142]
Мы уже победили, просто это еще не так заметно...
Re[8]: Языки запросов в объектно-ориентированных СУБД
Здравствуйте, Merle, Вы писали: M>По какому принципу он догадывается, как именно оптимальнее всего "кластеризовать" объекты? M>Ведь кластеризация — это штука такая, с одинаковым успехом может как поднять производительность, так и просадить.
Там все явно задается. По дефолту, скорее всего, он оптимизирует сканы по коллекциям — т.е. тупо кладет "записи" одну за другой.
... << RSDN@Home 1.1.4 @@subversion >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[7]: Языки запросов в объектно-ориентированных СУБД
Здравствуйте, Gaperton, Вы писали: G>Точно были. Это основное и единственное, что меня интересовало. Так как Gemstone — это смоллток-система с персистентными объектами, то в общих чертах все и так понятно. Остается один вопрос — есть ли кластреный индекс; если есть — производительности должно хватить, так как все равно в диск упремся. Если нет — то засада.
G>И в доке я это нашел. "Кластер" создается отдельно, объекты которые к нему относятся располагаются на диске подряд. По возможности конечно.
Создается у меня впечатление, что ты путаешь кластер и кластерный индекс. Кластеры в ODBMS используются для оптимизации навигационных запросов, чтобы "близкие" объекты располагались по возможности на одной странице. А кластерный индекс означает совместное расположение записей с близким значеним ключа, и пригоден для оптимизации range-seek запросов. G>Впрочем, дальше чтения доки дело у меня не пошло — не хватило времени+желания+необходимости. Напишешь впечатления, если разберешься?
Обязательно напишу. Пока что впечатления сугубо негативные:
— инсталлер сработал со второго раза, до перезагрузки упорно рассказывал мне про нехватку ресурсов подсистеме Win16. Ага, а в Requirements написано не ниже Win2000.
— при запуске он выдает на экран путь к логу. При этом на самом деле пишет лог в совсем другое место. Я полчаса потратил только на то, чтобы понять, почему он не взлетает:
— дело в том, что в поставке идет временная лицензия, истекшая в июне. В форуме по суппорту — 2 (!) ответа за все время его существования. Мэйллист, правда, имеет более богатую историю, но он приватный. Я отправил запрос на подписку, жду ответа.
В общем, Gemstone не выглядят ребятами, которым нужны клиенты. Им, похоже, и без нас хорошо.
Ладно, посмотрим в полный рост, когда наконец удастся поднять этого зверя.
... << RSDN@Home 1.1.4 @@subversion >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[8]: Языки запросов в объектно-ориентированных СУБД
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Gaperton, Вы писали: G>>Точно были. Это основное и единственное, что меня интересовало. Так как Gemstone — это смоллток-система с персистентными объектами, то в общих чертах все и так понятно. Остается один вопрос — есть ли кластреный индекс; если есть — производительности должно хватить, так как все равно в диск упремся. Если нет — то засада.
G>>И в доке я это нашел. "Кластер" создается отдельно, объекты которые к нему относятся располагаются на диске подряд. По возможности конечно. S>Создается у меня впечатление, что ты путаешь кластер и кластерный индекс. Кластеры в ODBMS используются для оптимизации навигационных запросов, чтобы "близкие" объекты располагались по возможности на одной странице. А кластерный индекс означает совместное расположение записей с близким значеним ключа, и пригоден для оптимизации range-seek запросов.
Под "кластерным индексом" в данном случае я понимаю возможность контроллировать физический порядок записей на диске. Естественно, "близкие" объекты должны лежать в одной странице на диске, чтобы получить мало-мальски приемлемую производительность (но не навигационных запросов! А именно range-seek. Если навигационные запросы распределены случайно, то нам вобщем все равно, сгруппированы близкие объекты или нет). А вот если близкие страницы идут по возможности подряд, то последовательная выборка будет раз минимум в 10 быстрее. Потому как за один оборот диска все прочтется. Ну, в лучшем случае .
Насколько я понял, понятие "кластера" в GemStone позволяет управлять физическим порядком записей. Все, больше ничего и не надо, т. к. выкрутится уже можно.
G>>Впрочем, дальше чтения доки дело у меня не пошло — не хватило времени+желания+необходимости. Напишешь впечатления, если разберешься? S>Обязательно напишу. Пока что впечатления сугубо негативные: S>... S>В общем, Gemstone не выглядят ребятами, которым нужны клиенты. Им, похоже, и без нас хорошо. S>Ладно, посмотрим в полный рост, когда наконец удастся поднять этого зверя.
Твоя решимость довести дело до победного конца внушает уважение Ждем!
Re[8]: Языки запросов в объектно-ориентированных СУБД
Здравствуйте, Merle, Вы писали:
M>Здравствуйте, Gaperton, Вы писали:
G>> Остается один вопрос — есть ли кластреный индекс; если есть — производительности должно хватить, так как все равно в диск упремся. M>По какому принципу он догадывается, как именно оптимальнее всего "кластеризовать" объекты? M>Ведь кластеризация — это штука такая, с одинаковым успехом может как поднять производительность, так и просадить.
Ты явно создаешь кластер, и явно относишь объекты к экземпляру кластера.
Re[6]: Языки запросов в объектно-ориентированных СУБД
Здравствуйте, 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.