Alexey Rovdo пишет:
> Мне кажется, что производители коммерческих продуктов берутся за все > это только по одной причине — желание соответствовать как можно > большему числу стандартов. Проприетарные решения не в чести у > покупателей, а альтернативы у ODMG пока нет (хотя бурное развитие JDO > можно рассматривать как заявку — и этот путь, полагаю, более верен, > чем путь ODMG).
Кхе, кхе. Может стоит посмотреть на RealLife(tm)? В мире Java сейчас
рулит Hibernate для OR-maping'а, JDO не прижился и не особо используется.
Здравствуйте, Cyberax, Вы писали: C>А что, если модель сложная, то РСУБД автоматически отпадают? )) Могу C>ткнуть носом в SAP, в котором сложная модель с 10000 таблиц.
Может быть. С SAP не знаком. Хотя само по себе количество таблиц не всегда определяет меру сложности. >> Простые запросы? Ты вообще когда-нибудь авиабилет покупал? Попробуй >> рассказать, сколько мне будет стоить билет >> Новосибирск-Франкфурт-Стамбул-Москва-Новосибирск. С учетом скидок и >> ограничений. C>Считаем маршрут от Новосибирска до Франкфурта (0 запросов — все станции C>вполне можно хранить в памяти),
Сколько есть таких маршрутов? C>затем считаем цену от Новосибирска до C>границы (опять же — 0 запросов) и проверяем доступность (1-2 запроса) C>свободных мест. Затем просим компанию, ответственную за перевозку от C>границы до Франкфурта сделать тоже самое.
Нда. Похоже, ты никогда на самолете не летал. Открою тебе тайну — нет такой штуки, как "цена от Новосибирска до границы". Во-первых, авиакомпаний — море. Во-вторых, каждая авиакомпания на любой рейс предоставляет от одного до десяти тарифов (в реальности как правило их около пяти). При этом правила применимости тарифа могут включать в себя очень много всяких подробностей, которые я грубияну пересказывать не буду. Раз ты такой умный — сходи и посмотри сам. Вся тонкость в том, что эти правила определяет сама авиакомпания.
В третьих, цена билета Нск-Мск-Франкфурт-Мск-Нск вовсе не равна сумме цен билетов Нск-Мск-Нск и Мск-Франкфурт-Мск.
Тебе никогда не выписывали такой билет, что потом представитель авиакомпании говорил "извините, но в таком сочетании эти скидки не предоставляются"? Это из-за того, что бизнес-логика записана на английском языке, а не на языке программирования. C>И я уж не говорю, что такие сложные заказы едва ли будут 1% от всех заказов.
Да-да. Для бухгалтера "почти никогда" == "не бывает". Для программиста "почти никогда" == "бывает".
... << RSDN@Home 1.1.4 beta 4 rev. 347>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Sinclair пишет:
> C>А что, если модель сложная, то РСУБД автоматически отпадают? )) Могу > C>ткнуть носом в SAP, в котором сложная модель с 10000 таблиц. > Может быть. С SAP не знаком. Хотя само по себе количество таблиц не > всегда определяет меру сложности.
Там сама предметная модель сложная — управление крупным предприятием.
>>> Простые запросы? Ты вообще когда-нибудь авиабилет покупал? Попробуй >>> рассказать, сколько мне будет стоить билет >>> Новосибирск-Франкфурт-Стамбул-Москва-Новосибирск. С учетом скидок и >>> ограничений. > C>Считаем маршрут от Новосибирска до Франкфурта (0 запросов — все станции > C>вполне можно хранить в памяти), > Сколько есть таких маршрутов?
Вряд ли больше, чем роутеров в сети Интернет. А ведь маршрут для
IP-пакета на tier-1 роутерах рассчитывается почти мгновенно.
Пусть во всем мире 100000 аэропортов, тогда количество возможных
маршрутов между ними — 10^10, и это верхняя граница. Это вполне в
пределах даже домашнего компьютера.
> C>затем считаем цену от Новосибирска до > C>границы (опять же — 0 запросов) и проверяем доступность (1-2 запроса) > C>свободных мест. Затем просим компанию, ответственную за перевозку от > C>границы до Франкфурта сделать тоже самое. > Нда. Похоже, ты никогда на самолете не летал. Открою тебе тайну — нет > такой штуки, как "цена от Новосибирска до границы".
Это я сглючил, не заметил слово "авиа" и подумал, что нужны ЖД-билеты. А
весело получается: авиабилет до границы
> Раз ты такой умный — сходи и посмотри сам. Вся тонкость в том, что эти > правила определяет сама авиакомпания. > В третьих, цена билета Нск-Мск-Франкфурт-Мск-Нск вовсе не равна сумме > цен билетов Нск-Мск-Нск и Мск-Франкфурт-Мск.
Ну и что? Когда мы нашли подходящий маршрут, то никто не мешает
переадресовать оценочный запрос серверам конкретных компаний.
> C>И я уж не говорю, что такие сложные заказы едва ли будут 1% от всех > заказов. > Да-да. Для бухгалтера "почти никогда" == "не бывает". Для программиста > "почти никогда" == "бывает".
Для программиста "почти никогда" == "можно не оптимизировать".
Здравствуйте, Cyberax, Вы писали:
C>Кхе, кхе. Может стоит посмотреть на RealLife(tm)? В мире Java сейчас C>рулит Hibernate для OR-maping'а, JDO не прижился и не особо используется.
Hibernate и JDO отличаются не так уж сильно — идеи, стоящие за этим двумя технологиями, очень схожи (отличаются в основном исполнения). Ну а насчет популярности мне выводы делать сложно, но кажется, что какого-то значительного отрыва нет ни у JDO, ни у Hibenate. Во всяком случае "не прижился" — это вы уже загнули.
Здравствуйте, Alexey Rovdo, Вы писали: AR>Из личной практики работы с продуктами Versant я вынес следующее. Запросы нужно использовать при работе с ООСУБД как можно реже. Причин тут несколько.
Совершенно верное замечание. AR>По моим личным впечатлениям декларативные языки запросов вообще не подходят для работы с ООСУБД — они не соответствуют объектной парадигме этих систем, вступая с ней в противоречие. Более понятным и продуктивным здесь может быть процедурный/функциональный подход к написанию запросов.
И с этим я тоже согласен.
Основная проблема произвольного декларативного языка запросов — взаимодействие с объектной моделью. Хорошо, когда все средства построения выражений-предикатов встроены прямо в язык. Когда в эту область вторгаются пользовательские типы и методы, происходит некоторая сложность. Хочется, чтобы язык запросов был вычислительно эквивалентен тому языку, который используется в определении поведения, т.е. кода методов. AR>И, кстати, производители ООСУБД этот подход поддерживают, хотя пока и нельзя сказать, что он сильно развит (далее все гипотетически, конкретных продуктов, работающих подобным образом я не знаю). Т.е. вместо OQL запроса вида: "SELECT * From ObjectClass Where ObjectClass.atrrib = const_Object" мы в ОО-программе пишем что-то вроде "database.GetCollecttion('ObjectClass', constObject.equals)" и получаем результат-коллекцию. Обычно это коллекция ссылок на объекты.
В данный момент я пытаюсь научиться оптимизировать запросы, заданные прямо на языке-носителе в императивном стиле. Предикат описывается не как некоторое функциональное выражение, а прямо как метод на управляемом языке:
AR>Но уже и в этом примере видно, что включение объекта Object в результирующую коллекцию происходит в зависимости от того, какой результат возвратит метод cons_Object.equals(Object). Как оптимизировать такие запросы, если код метода equals может быть очень сложным?
Конвертировать императивный код в функциональное представление. Это можно сделать благодаря реверсируемости управляемого кода. AR>Где отрабатывать код метода?
Ессно на сервере AR>Чтобы создать систему, действительно способную оптимизировать такие запросы, разработчикам ООСУБД еще предстоит много и много потрудиться
Угу. Самое печальное, что заниматься этим совершенно некогда. За науку денег не платят — приходится упражняться урывками.
... << RSDN@Home 1.1.4 beta 4 rev. 347>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
C>Вряд ли больше, чем роутеров в сети Интернет. А ведь маршрут для C>IP-пакета на tier-1 роутерах рассчитывается почти мгновенно.
Гм. Насколько мне известно, маршрутизация IP пакетов происходит независимо на каждом шаге. Нет никакого централизованного сервиса построения полного маршрута. C>Пусть во всем мире 100000 аэропортов, тогда количество возможных C>маршрутов между ними — 10^10, и это верхняя граница. Это вполне в C>пределах даже домашнего компьютера. C>Ну и что? Когда мы нашли подходящий маршрут, то никто не мешает C>переадресовать оценочный запрос серверам конкретных компаний.
Ну вот "никто не мешает" почему-то не работает. C>Для программиста "почти никогда" == "можно не оптимизировать".
Дело не в оптимизации. Пойми, что проблема не в низкой эффективности! Проблема в том, что такой системы, как ты рассказываешь, в природе не существует.
... << RSDN@Home 1.1.4 beta 4 rev. 347>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Alexey Rovdo пишет:
> C>Кхе, кхе. Может стоит посмотреть на RealLife(tm)? В мире Java сейчас > C>рулит Hibernate для OR-maping'а, JDO не прижился и не особо > используется. > Hibernate и JDO отличаются не так уж сильно — идеи, стоящие за этим > двумя технологиями, очень схожи (отличаются в основном исполнения).
Идеи JDO 1.0 и Hibernate отличаются весьма сильно, JDO — это стандарт
для объектного persistance'а, а Hibernate — именно OR-maping. Поэтому
JDOQL имеет весьма узкую функциональность (Sun как обычно попыталась
сделать самый общий стандарт) по сравнению с HQL. Кроме того, в JDO1.1
не специфицирован сам формат OR-mapping'а. В JDO 2.0 исправлены многие
недостатки, но этот стандарт опоздал на год-два (политика, блин).
> Ну а насчет популярности мне выводы делать сложно, но кажется, что > какого-то значительного отрыва нет ни у JDO, ни у Hibenate. Во всяком > случае "не прижился" — это вы уже загнули.
Sinclair пишет:
> В данный момент я пытаюсь научиться оптимизировать запросы, заданные > прямо на языке-носителе в императивном стиле. Предикат описывается не > как некоторое функциональное выражение, а прямо как метод на > управляемом языке: > >public static bool AcceptVisitor(Person visitor) >{ > return (visitor.Age > 21); >} > >
А сколько времени будет работать такой запрос, если в базе 10000000
человек?
Cyberax пишет: >>public static bool AcceptVisitor(Person visitor) >>{ >> return (visitor.Age > 21); >>} >> >> > А сколько времени будет работать такой запрос, если в базе 10000000 > человек?
В GLORP используется такой подход — вместо реального объекта в
блок-фильтр подсовывается специальный объект который накапливает все
посылаемые ему сообщения. Из этой информации затем и генерируется запрос
к серверу.
--
Andrei N.Sobchuck
JabberID: andreis@jabber.ru. ICQ UIN: 46466235.
Sinclair пишет:
> C>Вряд ли больше, чем роутеров в сети Интернет. А ведь маршрут для > C>IP-пакета на tier-1 роутерах рассчитывается почти мгновенно. > Гм. Насколько мне известно, маршрутизация IP пакетов происходит > независимо на каждом шаге. Нет никакого централизованного сервиса > построения полного маршрута.
Маршрутизация в IP — смешанная. Пакеты идут hop-by-hop маршрутизацией,
но маршруты на каждом хосте рассчитываются со знанием всей топологии сети.
> C>Пусть во всем мире 100000 аэропортов, тогда количество возможных > C>маршрутов между ними — 10^10, и это верхняя граница. Это вполне в > C>пределах даже домашнего компьютера. > C>Ну и что? Когда мы нашли подходящий маршрут, то никто не мешает > C>переадресовать оценочный запрос серверам конкретных компаний. > Ну вот "никто не мешает" почему-то не работает.
Работает. http://www.aviatrans.ru/index.html например.
> C>Для программиста "почти никогда" == "можно не оптимизировать". > Дело не в оптимизации. Пойми, что проблема не в низкой эффективности! > Проблема в том, что такой системы, как ты рассказываешь, в природе не > существует.
Почему нет, когда я своими глазами ее в Канаде ее видел? И главное, я не
знаю причин (даже организационного характера), по которым она невозможна.
Andrei N.Sobchuck wrote: > Cyberax пишет: > >>>public static bool AcceptVisitor(Person visitor) >>>{ >>> return (visitor.Age > 21); >>>} >>> >>> >> >>А сколько времени будет работать такой запрос, если в базе 10000000 >>человек? > > > В GLORP используется такой подход — вместо реального объекта в > блок-фильтр подсовывается специальный объект который накапливает все > посылаемые ему сообщения. Из этой информации затем и генерируется запрос > к серверу. >
Можно построить запрос на основе декомпиляции байт-кода, так сделано в
ReStore. Это покрывает большее количество случаев.
Andrei N.Sobchuck пишет:
>> А сколько времени будет работать такой запрос, если в базе 10000000 >> человек? > В GLORP используется такой подход — вместо реального объекта в > блок-фильтр подсовывается специальный объект который накапливает все > посылаемые ему сообщения. Из этой информации затем и генерируется запрос > к серверу.
И что? Каким образом фильтр поймет, что нужно выполнить выборку по всем
людям с возрастом больше 27 лет?
Сложность все равно O(n) останется, тогда как в RDB в таблице с индексом
по возрасту этот запрос займет O(log n) времени.
Конечно, можно взять в ООБД отсортированную по возрасту коллекцию людей,
и потом уже по ней выполнить поиск, но такой подход будет изморфен RDBшному.
Здравствуйте, _vovin, Вы писали: _>Можно построить запрос на основе декомпиляции байт-кода, так сделано в _>ReStore. Это покрывает большее количество случаев.
Можно ссылочку на ReStore?
... << RSDN@Home 1.1.4 beta 4 rev. 347>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Cyberax, Вы писали: C>А сколько времени будет работать такой запрос, если в базе 10000000 C>человек?
Все зависит от того, как реализованы геттеры свойства Age в потомках класса Person В нормальном случае ~ ln(1000000).
... << RSDN@Home 1.1.4 beta 4 rev. 347>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
_vovin пишет:
>> В GLORP используется такой подход — вместо реального объекта в >> блок-фильтр подсовывается специальный объект который накапливает все >> посылаемые ему сообщения. Из этой информации затем и генерируется запрос >> к серверу. >> > Можно построить запрос на основе декомпиляции байт-кода, так сделано в > ReStore. Это покрывает большее количество случаев.
Это покрывает только тривиальные случаи типа "age>23 and height>180".
Как декомпилировать и осмыслить сложный запрос с join'ами (которые в ИЯ
превратятся в циклы) — мне непонятно.
Cyberax wrote:
> _vovin пишет: > > >>>В GLORP используется такой подход — вместо реального объекта в >>>блок-фильтр подсовывается специальный объект который накапливает все >>>посылаемые ему сообщения. Из этой информации затем и генерируется запрос >>>к серверу. >>> >> >>Можно построить запрос на основе декомпиляции байт-кода, так сделано в >>ReStore. Это покрывает большее количество случаев. > > > Это покрывает только тривиальные случаи типа "age>23 and height>180". > Как декомпилировать и осмыслить сложный запрос с join'ами (которые в ИЯ > превратятся в циклы) — мне непонятно. >
Даже упомянутый случай с GLORP-ом отлично решает эту проблему.
Построенное синтаксическое дерево исходного языка (некоторого
подмножества) отображается на SQL и дальше выполняется обычный запрос.
Это уже пройденный этап. А главная проблема связана с полиморфизмом.
Sinclair wrote:
> Здравствуйте, _vovin, Вы писали: > _>Можно построить запрос на основе декомпиляции байт-кода, так сделано в > _>ReStore. Это покрывает большее количество случаев. > Можно ссылочку на ReStore?
Здравствуйте, Cyberax, Вы писали:
C>Сложность все равно O(n) останется, тогда как в RDB в таблице с индексом C>по возрасту этот запрос займет O(log n) времени.
А кто в ООБД отменил индексы?
C>Конечно, можно взять в ООБД отсортированную по возрасту коллекцию людей, C>и потом уже по ней выполнить поиск, но такой подход будет изморфен RDBшному.
И что в этом плохого? К тому же — индекс можно строить независимо от вида коллекции.
Sinclair пишет:
> From: *Sinclair* </Users/Profile.aspx?uid=5743> rsdn > </search/?group=27> </Users/Private/AddFav.aspx?mid=1111513> > <NewMsg.aspx?gid=27> <NewMsg.aspx?mid=1111513> <?mid=1111513> > <Message.aspx?mid=1111513#1111513> <NewMsg.aspx?mid=1111513&edit=1> > <Private/Self.aspx?mid=1111513> > > Здравствуйте, Cyberax, Вы писали: > C>А сколько времени будет работать такой запрос, если в базе 10000000 > C>человек? > Все зависит от того, как реализованы геттеры свойства Age в потомках > класса Person В нормальном случае ~ ln(1000000).
Причем тут getter'ы? Пусть алгоритм поиска выглядит так:
Schools schools=getAllSchools();
for(int x=0;x<coll.size();x++)
{
Human h=coll.get(x);
if (h.getAge()>27)
{
for (int y=0;y<schools.size();y++)
if (schools.get(x).getStudents().hasObject(h))
resultColl.add(h);
}
}
Для случая RDB такой алгоритм будет работать O(n) без индексов и O(log
n) с индексами.
Если его соптимизировать в его ОО-воплощении, то получится опять тот же
реляционный алгоритм.
GlebZ пишет:
> C>Сложность все равно O(n) останется, тогда как в RDB в таблице с > индексом > C>по возрасту этот запрос займет O(log n) времени. > А кто в ООБД отменил индексы?
Никто.
> C>Конечно, можно взять в ООБД отсортированную по возрасту коллекцию > людей, > C>и потом уже по ней выполнить поиск, но такой подход будет изморфен > RDBшному. > И что в этом плохого? К тому же — индекс можно строить независимо от > вида коллекции.
Тогда непонятно ЧЕМ же OODB отличается от RDB.
Единственное отличие: в OODB идентификатором объекта является OID, в
котором возможно закодировать физическое расположение объекта на диске,
а в RDB идетификтором строки является логический PK. Но это уже слишком
незначительная деталь.
)) Могу 
