Здравствуйте, borisman2, Вы писали:
B>Советы.
B>Не пытайтейсь одинаково осмысливать РСУБД, сетевые базы, иерархические базы и ООБД. ООБД отличаются диаметрально, т.к. работают не с данными по сути, а с поведением объектов.
B>Лучше не пытайтесь применить язык запросов в ООБД. Хлопот не оберетесь. Пишите старый добрый навигационный код.
Именно это и сдерживает их применение. Старый добрый навигационный код надо отлизывать руками для достижения приемлемой производительности. Это означает, что вопросы производительности дают "отдачу" по рукам архитектору сельнее, чем противотанковое ружье. А ответы на эти вопросы зачастую невозможно получить до развертывания системы. В итоге мы имеем единичные success stories, где архитектору удалось угадать особенности применения и заложить удачное решение. А РДБМС благодаря декларативности позволяют дотюнить решение уже на этапе эксплуатации без изменений в клиентском или бизнес-коде.

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

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

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

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

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

G>>Впрочем, дальше чтения доки дело у меня не пошло — не хватило времени+желания+необходимости. Напишешь впечатления, если разберешься?
S>Обязательно напишу. Пока что впечатления сугубо негативные:
S>...
S>В общем, Gemstone не выглядят ребятами, которым нужны клиенты. Им, похоже, и без нас хорошо.
S>Ладно, посмотрим в полный рост, когда наконец удастся поднять этого зверя.
Твоя решимость довести дело до победного конца внушает уважение Ждем!

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

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

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

Ты явно создаешь кластер, и явно относишь объекты к экземпляру кластера.

Здравствуйте, 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

Здравствуйте, 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.

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

L>Но это не мешает ему все-таки предпочитать Java/C# + ORM + RDBMS. Потому и говорю, что его аллергия ничем не мотивирована в техническом плане. Скорее всего проблема в том, что заказчики не доверяют технологии ООСУБД; их слух ласкает слово Oracle.
Скорее всего проблема в том, что OODBMS в настоящее время настолько далеки от возможностей RDBMS по обработке действительно больших объемов данных, что никто не хочет платить лишнего. Как только речь заходит о настоящем OLTP, вперед выдвигается тройка Oracle+MS SQL+DB2. Никакими ODBMS тут даже не пахнет.