Re[19]: Объектные базы как они есть
От: Cyberax Марс  
Дата: 07.04.05 10:11
Оценка:
_vovin пишет:

>> Это покрывает только тривиальные случаи типа "age>23 and height>180".

>> Как декомпилировать и осмыслить сложный запрос с join'ами (которые в ИЯ
>> превратятся в циклы) — мне непонятно.
> Даже упомянутый случай с GLORP-ом отлично решает эту проблему.
> Построенное синтаксическое дерево исходного языка (некоторого
> подмножества) отображается на SQL и дальше выполняется обычный запрос.

В доке на Restore я вижу только простенькие примеры типа "allPersons
select: [ :each | each dateOfBirth year = 1970]." Чего-то сложного я там
не вижу.

Тот же Hinernate с HQL покрывает _значительно_ большую функциональность.
И при этом реально работает.

> Это уже пройденный этап. А главная проблема связана с полиморфизмом.


А в чем с нима проблема? Он замечательно ложится на RDB.

--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[17]: Объектные базы как они есть
От: Sinclair Россия https://github.com/evilguest/
Дата: 07.04.05 10:44
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Причем тут getter'ы? Пусть алгоритм поиска выглядит так:

C>
C>Schools schools=getAllSchools();
C>for(int x=0;x<coll.size();x++)
C>{
C>    Human h=coll.get(x);
C>    if (h.getAge()>27)
C>    {
C>       for (int y=0;y<schools.size();y++)
C>          if (schools.get(x).getStudents().hasObject(h))
C>           resultColl.add(h);
C>    }
C>}
C>

Нет уж, пусть он так не выглядит. Во-первых, в нем ошибка (что ясно показывает тупиковость попыток вручную "помочь" серверу выполнить поиск). Во-вторых, никто не собирается пытаться оптимизировать алгоритмы.
От программиста требуется предоставить предикат, а среда обеспечит эффективный поиск объектов, удовлетворяющих этому предикату.
Вот как будет выглядеть предикат на C# 2.0 для твоего примера:
public static bool Predicate(Human h)
{
    if (h.Age<=27)
        return false;
        
  foreach(School school in Schools)
    {
        if school.Students.Contains(h)
            return true;
    }
    return false;
}

Естественно, подобный код вряд ли удастся как-то сильно оптимизировать. Но ведь ты на SQL не станешь искать школьников при помощи курсора? Вот и тут — воспользуемся тем фактом, что мы ищем учеников любой школы:
public static bool Predicate(Human h)
{
    return (h.Age>27) && (AllStudents.Contains(h));
}

Оптимизатор будет вполне способен увидеть здесь join.

C>Для случая RDB такой алгоритм будет работать O(n) без индексов и O(log

C>n) с индексами.
Гм. n — это что?

C>Если его соптимизировать в его ОО-воплощении, то получится опять тот же

C>реляционный алгоритм.
Естественно! Цель как раз в том и состоит, чтобы получить алгоритм, близкий к реляционному. Только без ручного затачивания под конкретные реализации, с поддержкой полиморфизма и инкапсуляции. В нормальной системе запрос, который ты хотел написать, будет вообще выглядеть примерно так:
public static bool Predicate(StudentRecord studentRecord)
{
    return (student.Person.Age>27);
}
...

foreach(IStudent student in GlobalExtent.Select(Predicate))
{
    System.Console.Writeln(student);
}
... << RSDN@Home 1.1.4 beta 4 rev. 347>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[19]: Объектные базы как они есть
От: Sinclair Россия https://github.com/evilguest/
Дата: 07.04.05 10:44
Оценка:
Здравствуйте, Cyberax, Вы писали:
C>Тогда непонятно ЧЕМ же OODB отличается от RDB.
Тем, что в RDB нет инкапсуляции, наследования и полиморфизма.
... << RSDN@Home 1.1.4 beta 4 rev. 347>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[15]: Объектные базы как они есть
От: GlebZ Россия  
Дата: 07.04.05 10:48
Оценка:
Здравствуйте, Alexey Rovdo, Вы писали:

AR>Мне кажется, что производители коммерческих продуктов берутся за все это только по одной причине — желание соответствовать как можно большему числу стандартов. Проприетарные решения не в чести у покупателей, а альтернативы у ODMG пока нет (хотя бурное развитие JDO можно рассматривать как заявку — и этот путь, полагаю, более верен, чем путь ODMG).

Поэтому и процветают ORM. У них нет понятия о стандартах, у них есть понятия об эффективности. В той степени которой они могут добиться. Тема ODMG уже надоела. Ну неживой он. Прошло столько времени с его создания. Они давно уже распустились. Зачем поддерживать то, чего уже практически нет.

GZ>>Запросы — это не столько получение некоторого набора объектов, а еще инструмент выполнения некоторых действий на некоторым множеством объектов.


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

Знать бы что такое спецификации ООП. Вообще это очень сложная задача. Я бы сказал чрезвычайно сложная. Может потому за нее и не беруться как крупные так и мелкие компании. Но вполне возможная. Я по крайней мере не вижу никаких противопоказаний. SQL — работает же с функциями.

С уважением, Gleb.
... << RSDN@Home 1.1.4 beta 4 rev. 358>>
Re[20]: Объектные базы как они есть
От: _vovin http://www.pragmatic-architect.com
Дата: 07.04.05 10:54
Оценка:
Cyberax wrote:

> _vovin пишет:

>
>
>>>Это покрывает только тривиальные случаи типа "age>23 and height>180".
>>>Как декомпилировать и осмыслить сложный запрос с join'ами (которые в ИЯ
>>>превратятся в циклы) — мне непонятно.
>>
>>Даже упомянутый случай с GLORP-ом отлично решает эту проблему.
>>Построенное синтаксическое дерево исходного языка (некоторого
>>подмножества) отображается на SQL и дальше выполняется обычный запрос.
>
>
> В доке на Restore я вижу только простенькие примеры типа "allPersons
> select: [ :each | each dateOfBirth year = 1970]." Чего-то сложного я там
> не вижу.
>
> Тот же Hinernate с HQL покрывает _значительно_ большую функциональность.
> И при этом реально работает.

ReStore это простенький инструмент.
Для более сложных вещей есть GLORP и Gemstone.

>

>
>>Это уже пройденный этап. А главная проблема связана с полиморфизмом.
>
>
> А в чем с нима проблема? Он замечательно ложится на RDB.
>

Ты уверен, что понял о чем идет речь?
Posted via RSDN NNTP Server 1.9
Re[20]: Объектные базы как они есть
От: Cyberax Марс  
Дата: 07.04.05 11:02
Оценка:
Sinclair пишет:

> C>Тогда непонятно ЧЕМ же OODB отличается от RDB.

> Тем, что в RDB нет инкапсуляции, наследования и полиморфизма.

В хранилище ООБД инкапсюляции нет, как и в RDB. Наследование и
полиморфизм замечательно выражаются в RDB в виде объединенных по PK
таблиц (возможно с полями-дискриминаторами).

То есть на практике объектные модели (за исключением самых извращенных)
вполне прилично ложатся в RDB.

--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[18]: Объектные базы как они есть
От: Cyberax Марс  
Дата: 07.04.05 11:09
Оценка:
Sinclair пишет:

> Вот как будет выглядеть предикат на C# 2.0 для твоего примера:

>
>public static bool Predicate(Human h)
>{
> if (h.Age<=27)
> return false;
>
> foreach(School school in Schools)
> {
> if school.Students.Contains(h)
> return true;
> }
> return false;
>}
>
>
На HQL это будет выглядеть так: "SELECT human FROM Human human, School
sc WHERE human IN sc.students". Гораздо понятнее, лаконичнее и ложится
совершенно естественным образом на SQL.

Причем в HQL есть group by, сортировки, джойны и т.п. В виде предикатов
это записывается весьма неудобно.

Предикатный поиск, кстати, в Hibernate тоже есть — называется Criteria API.

>public static bool Predicate(Human h)

>{
> return (h.Age>27) && (AllStudents.Contains(h));
>}
>
>
> Оптимизатор будет вполне способен увидеть здесь join.

А если мы сделаем так:
public static bool Predicate(Human h)

{
    return (sin(h.Age)>0.2763) && (AllStudents.Contains(h));
}


> C>Для случая RDB такой алгоритм будет работать O(n) без индексов и O(log

> C>n) с индексами.
> Гм. n — это что?

Количество школ или людей — что больше.

--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[21]: Объектные базы как они есть
От: GlebZ Россия  
Дата: 07.04.05 11:10
Оценка: +1
Здравствуйте, Cyberax, Вы писали:

C>Sinclair пишет:


>> C>Тогда непонятно ЧЕМ же OODB отличается от RDB.

>> Тем, что в RDB нет инкапсуляции, наследования и полиморфизма.

C>В хранилище ООБД инкапсюляции нет, как и в RDB.

В хранилище нет. В ООDB да. В хранилище ООБД только состояние объектов.
C>Наследование и
C>полиморфизм замечательно выражаются в RDB в виде объединенных по PK
C>таблиц (возможно с полями-дискриминаторами).
Это всего лишь один из самых простых и самых неэффективных способов маппирования объектов в RDBMS.

C>То есть на практике объектные модели (за исключением самых извращенных)

C>вполне прилично ложатся в RDB.
Ну почти да. Только для этого нужно очень много дописать. И учитывая удаленность хранилища и самой системы эффективности достойной ООДБ ты точно не получишь

С уважением, Gleb.
... << RSDN@Home 1.1.4 beta 4 rev. 358>>
Re[21]: Объектные базы как они есть
От: Sinclair Россия https://github.com/evilguest/
Дата: 07.04.05 11:26
Оценка:
Здравствуйте, Cyberax, Вы писали:
C>В хранилище ООБД инкапсюляции нет, как и в RDB.
C> Наследование и полиморфизм замечательно выражаются в RDB в виде объединенных по PK
C>таблиц (возможно с полями-дискриминаторами).
Существующие решения никакого полиморфизма не предоставляют.
C>вполне прилично ложатся в RDB.
Нормальный полиморфизм ты в RDB запаришься складывать. Точнее, внесение малейших изменений потребует перетряхивания значительной части схемы.
... << RSDN@Home 1.1.4 beta 4 rev. 347>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[21]: Объектные базы как они есть
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 07.04.05 11:43
Оценка:
Cyberax пишет:
> То есть на практике объектные модели (за исключением самых извращенных)
> вполне прилично ложатся в RDB.

В репозитории для VW ST лежит пакет позволяющий сохранить любой объект в
БД без написания мапов. Задействовано вроде 6 таблиц (не помню точно).
Думаю для java сделать такое — тоже без проблем.

--
Andrei N.Sobchuck
JabberID: andreis@jabber.ru. ICQ UIN: 46466235.
Posted via RSDN NNTP Server 1.9
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[15]: Объектные базы как они есть
От: GlebZ Россия  
Дата: 07.04.05 11:49
Оценка:
Здравствуйте, eao197, Вы писали:


[скипнуто в знак согласия]
Именно. А теперь представь себе, над одним и тем-же состоянием работают несколько отделов. Любое изменение должно быть состояния должно изменить код каждого из них. Иногда не знаешь, что было изменение от разработчика за соседним компьютером, а тут вообще плохо. Нужна единая прокладка между состоянием и пользователя состояния.
Однако — ты предлагал накладывать несколько реализаций на одно и то же состояние.Re[4]: Объектные базы как они есть
Автор: eao197
Дата: 05.04.05
Что меня и возмутило. Объект накладываемый на состояние — священная корова отвечающая за согласованность состояния. Грешно мучить эту корову. Всем придется плохо. А что будет сверху — делегирования, аггрегация, какие-то внешние сервисы... Это уже другой вопрос.

С уважением, Gleb.
... << RSDN@Home 1.1.4 beta 4 rev. 358>>
Re[16]: Объектные базы как они есть
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 07.04.05 12:14
Оценка:
Здравствуйте, GlebZ, Вы писали:

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



GZ>[скипнуто в знак согласия]

GZ>Именно. А теперь представь себе, над одним и тем-же состоянием работают несколько отделов. Любое изменение должно быть состояния должно изменить код каждого из них. Иногда не знаешь, что было изменение от разработчика за соседним компьютером, а тут вообще плохо.

Для контроля изменений коллеги-разработчика применяются системы контроля версий
Мы, например, даже на боевые сервера системы устанавливаем через систему контроля версий

GZ> Нужна единая прокладка между состоянием и пользователя состояния.


А если серьезно, то здесь есть большая проблема, которая требует решения.
Причем для неуправляемого C++ это более серьезный вопрос, чем для управляемых языков/сред. Но и там так же могут быть проблемы. Например, если тянуть код объектов с сервера, то при изменении версии софта на сервере может потребоваться скачивать слишком большой объем кода. Даже если он и закэшируется на клиенте для последующего использования, то первоначальная загрузка может стать очень дорогой (особенно если с кодом объекта потянутся и его зависимости). Кроме того, как быть системам, которые работают в режиме 24x7? Делает клиент очередной запрос на сервер за объектом, а сервер ему и отвечает: дорогой, закачай-ка сначала мегабайт-другой нового кода, а затем я тебе объект отдам. За время этой закачки все транзакции данного клиента тихо по тайм-ауту умирают

Можно сделать как в случае с серверами приложений и тонким клиентом. Клиент только инициирует запрос, который реально выполняется на сервере, рядом с ООСУБД сервером. Но в этом случае обновление версии софта для сервера приложений является простой технической задачей. Даже для систем 24x7. Но такой подход вряд ли возможен для CAD систем.

Еще один подход состоит в том, чтобы сервер понимал версии клиентов. И умел проводить модификацию данных на лету. Т.е. изменилась схема данных на сервере, а объект запросил старый клиент, сервер отдал клиенту объект в старой схеме данных. Получил сервер от старого клиента объект -- преобразовал его к новому виду и сохранил в БД. Такой подход, как мне помниться, у Константина Книжника в Goods был реализован.

GZ>Однако — ты предлагал накладывать несколько реализаций на одно и то же состояние.Re[4]: Объектные базы как они есть
Автор: eao197
Дата: 05.04.05
Что меня и возмутило. Объект накладываемый на состояние — священная корова отвечающая за согласованность состояния. Грешно мучить эту корову. Всем придется плохо. А что будет сверху — делегирования, аггрегация, какие-то внешние сервисы... Это уже другой вопрос.


Да, но хотелось бы, чтобы при извлечении объекта из БД не приходилось вручную агрегировать его в какой-то специфический прикладной объект. А то получится как с парсингом данных в XML -- поднимаем из XML DOM-дерево, пробегаем по нему и строим дерево нужных объектов для дальнейшей работы (тоже самое можно и с SAX парсингом делать). Вот этой лишней ручной работы не хотелось бы.
... << RSDN@Home 1.1.4 beta 4 rev. 303>>


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[22]: Объектные базы как они есть
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 07.04.05 12:14
Оценка:
Здравствуйте, Sinclair, Вы писали:

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

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

Но ведь полиморфизм относится к коду объектов. Так зачем его в RDB складывать?
... << RSDN@Home 1.1.4 beta 4 rev. 303>>


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[17]: Объектные базы как они есть
От: GlebZ Россия  
Дата: 07.04.05 13:02
Оценка:
Здравствуйте, eao197, Вы писали:

GZ>> Нужна единая прокладка между состоянием и пользователя состояния.


E>А если серьезно, то здесь есть большая проблема, которая требует решения.

E>Причем для неуправляемого C++ это более серьезный вопрос, чем для управляемых языков/сред. Но и там так же могут быть проблемы. Например, если тянуть код объектов с сервера, то при изменении версии софта на сервере может потребоваться скачивать слишком большой объем кода. Даже если он и закэшируется на клиенте для последующего использования, то первоначальная загрузка может стать очень дорогой (особенно если с кодом объекта потянутся и его зависимости). Кроме того, как быть системам, которые работают в режиме 24x7? Делает клиент очередной запрос на сервер за объектом, а сервер ему и отвечает: дорогой, закачай-ка сначала мегабайт-другой нового кода, а затем я тебе объект отдам. За время этой закачки все транзакции данного клиента тихо по тайм-ауту умирают

E>Можно сделать как в случае с серверами приложений и тонким клиентом. Клиент только инициирует запрос, который реально выполняется на сервере, рядом с ООСУБД сервером. Но в этом случае обновление версии софта для сервера приложений является простой технической задачей. Даже для систем 24x7. Но такой подход вряд ли возможен для CAD систем.

А для CAD важен 24x7(с ними не работал)?

E>Еще один подход состоит в том, чтобы сервер понимал версии клиентов. И умел проводить модификацию данных на лету. Т.е. изменилась схема данных на сервере, а объект запросил старый клиент, сервер отдал клиенту объект в старой схеме данных. Получил сервер от старого клиента объект -- преобразовал его к новому виду и сохранил в БД. Такой подход, как мне помниться, у Константина Книжника в Goods был реализован.

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


E>Да, но хотелось бы, чтобы при извлечении объекта из БД не приходилось вручную агрегировать его в какой-то специфический прикладной объект. А то получится как с парсингом данных в XML -- поднимаем из XML DOM-дерево, пробегаем по нему и строим дерево нужных объектов для дальнейшей работы (тоже самое можно и с SAX парсингом делать). Вот этой лишней ручной работы не хотелось бы.

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

С уважением, Gleb.
... << RSDN@Home 1.1.4 beta 4 rev. 358>>
Re[23]: Объектные базы как они есть
От: Sinclair Россия https://github.com/evilguest/
Дата: 07.04.05 13:13
Оценка: 7 (2)
Здравствуйте, eao197, Вы писали:

E>Но ведь полиморфизм относится к коду объектов. Так зачем его в RDB складывать?

Дело не в том, чтобы складывать. Дело в том, что мы выполняем запрос
select * from IPerson p where p.Age>27;

Здесь IPerson — интерфейс, Age — виртуальное свойство. Должен вернуться список объектов, реализующих IPerson. C соответствующими значениями Age.
В этом примитивном случае мы, конечно, сможем пойти одним из нескольких путей:
1. Построить view, в котором поле Age возвращается соответствующим способом для каждого класса:
create view IPerson as
select ID, Age from Person1
union 
select ID, DateDiff(Year, GetDate(), Birthdate) from Person2

2. Принудительно создать поле Age, которое будет кэшировать значение свойства Age.
Включить в методы, изменяющие состояние объекта, соответствующий код пересчета (в простом случае это поле просто будет в некоторых таблицах вычисляемым)

Увы, в более интересных случаях ничего удобного сделать не удастся. Представь себе портал развлечений. Зададим ему вопрос: на какие события я (зарегистрированный участник) смогу пойти сегодня? В SQL-стиле это будет примерно так:
select * from Events e where e.Accepts(@me) and e.Begins between GetDate() and Tomorrow();

Проблема в том, что каждый потомок класса Event определяет свои правила контроля посетителей. В каком-то классе Accepts всегда вернет true, в каких-то — проверит возраст, и так далее. Это и есть полиморфизм.
Решить эту проблему не так уж сложно. Для каждой конкретной объектной модели мы сможем построить конечный код:
create procedure GetAcceptableEvents (@me Person)
as
  select ID from MovieSessions ms 
    inner join Movie m on ms.Movie = m.ID
      inner join MovieCategory с on m.Category = c.ID
      where c.MinAge<=@me.Age
            and ms.StartTime between GetDate() and Tomorrow()
union 
  select ID from PeepShow ps where @me.Gender = MALE and @me.Age>=21
            aand ps.StartTime between GetDate() and Tomorrow()
union
  ...

Я намеренно упростил определение — этот код хоть и похож на T-SQL, не станет работать как минимум до MS SQL 2005. SQL 2000 — совместимый код будет посложнее, т.к. придется передавать все компоненты Person по отдельности.
Но уже здесь виден основной косяк: при добавлении в систему очередного типа развлечения, эту процедуру придется переписывать. А все потому, что мы были вынуждены "складывать полиморфизм в RDB". Иначе мы не могли эффективно получать результат нашего запроса. Нет, конечно, мы могли выполнить фильтрацию по хранимым атрибутам на стороне RDB, а уже потом выполнить остальную часть предиката на уровне сервера приложений. Но это немногим лучше — с точки зрения эффективности, мы игнорируем часть потенциально полезных индексов, а с точки зрения производительности труда должны учитывать все эти подробности еще на уровне проектирования, а не реализации, делая рутинную работу вручную.
... << RSDN@Home 1.1.4 beta 4 rev. 347>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[19]: Объектные базы как они есть
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 07.04.05 13:15
Оценка:
Cyberax пишет:

> На HQL это будет выглядеть так: "SELECT human FROM Human human, School

> sc WHERE human IN sc.students". Гораздо понятнее, лаконичнее и ложится
> совершенно естественным образом на SQL.

{ты забыл про возраст}
Кстати, мне кажется, что выборка "Human human" и объединение через
"human IN sc.students" выглядит понятно в SQL, но не совсем очевидно в
случае объектов. Ведь нужно что? — у каждой школы, выбрать учеников с
определённым возрастом. Типа, выбрать фамилии пиплов из примера выше:

Schools
   collect: [:school | school students surname]
   where: [:school | school students age <= 27]


> Причем в HQL есть group by, сортировки, джойны и т.п. В виде предикатов

> это записывается весьма неудобно.

Пример выше с сортировкой на GLORP выглядит так:

glorpSession
   readManyOf: Human
   where: [:each | each school notNIL and: [each age <= 27]]
   orderBy: #surname


Совсем не неудобно. Естественно связь Human-2-School нужно задать в
мапе. Если хочется произвольных связей, то тогда получится заметно
многословнее:

glorpSession returningManyOf: Human where: [:each |
   each exists: (Query readManyOf: Schools where: [:eachSchool |
       (eachSchool students
         anySatisfy: [:eachHuman | eachHuman = each)])].


> А если мы сделаем так:

>
> public static bool Predicate(Human h)
>
> {
> return (sin(h.Age)>0.2763) && (AllStudents.Contains(h));
> }

Функции, которые мапятся на sql — мапим, которые не мапятся — возможны
варианты.

--
Andrei N.Sobchuck
JabberID: andreis@jabber.ru. ICQ UIN: 46466235.
Posted via RSDN NNTP Server 1.9
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[18]: Объектные базы как они есть
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 07.04.05 13:19
Оценка:
Здравствуйте, GlebZ, Вы писали:

E>>Можно сделать как в случае с серверами приложений и тонким клиентом. Клиент только инициирует запрос, который реально выполняется на сервере, рядом с ООСУБД сервером. Но в этом случае обновление версии софта для сервера приложений является простой технической задачей. Даже для систем 24x7. Но такой подход вряд ли возможен для CAD систем.

GZ>А для CAD важен 24x7(с ними не работал)?

Для мелких CAD наверняка не важен. Но, если представить себе какую-нибудь систему автоматизированного проектирования самолетов (с сохранением данных в БД) на которой одновременно работают люди в разных концах земли, то 24x7 может быть необходим.

Когда-то давно я слышал байку, что для какой-то системы проектирования какого-то очередного Боинга была выбрана ООСУБД именно потому, что только она смогла обеспечить необходимую функциональность и производительность. И где размер одного чертежа превышал 4Gb. (Если мне окончательно не отшибает память, то это была то ли ObjectivityDB, то ли ObjectStore. Или Versant).

E>>Еще один подход состоит в том, чтобы сервер понимал версии клиентов. И умел проводить модификацию данных на лету. Т.е. изменилась схема данных на сервере, а объект запросил старый клиент, сервер отдал клиенту объект в старой схеме данных. Получил сервер от старого клиента объект -- преобразовал его к новому виду и сохранил в БД. Такой подход, как мне помниться, у Константина Книжника в Goods был реализован.

GZ>Вот именно поэтому есть полиформизм, инкапсуляция и интерфейсы.
GZ>Интерфейс — это некоторая соглашение того, что объект умеет делать какой-то набор действий. Напрямую ни схема данных хранилища ООБД, ни сами данные клиенту не доступны. Он может оперировать только интерфейсами. Реализация интерфейсов зависит от других людей. И если эти люди решили, что пользователю можно оставить старую версию интерфейса и сделать новую — то никаких особых проблем не существует.(главное не доводить это до маразма ActiveX). У меня системы именно по такому принципу действуют. При подключении на сервер имен, клиент дает свою версию. Ну и сервер имен отдает те интерфейсы которые могут работать с данной версией клиента.

И это правильно.

E>>Да, но хотелось бы, чтобы при извлечении объекта из БД не приходилось вручную агрегировать его в какой-то специфический прикладной объект. А то получится как с парсингом данных в XML -- поднимаем из XML DOM-дерево, пробегаем по нему и строим дерево нужных объектов для дальнейшей работы (тоже самое можно и с SAX парсингом делать). Вот этой лишней ручной работы не хотелось бы.

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

Да, выходит, что ты правильно меня понял (точнее, я в конце-концов смог внятно изложить свою позицию).
... << RSDN@Home 1.1.4 beta 4 rev. 303>>


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[16]: Объектные базы как они есть
От: Poudy Россия  
Дата: 07.04.05 19:40
Оценка:
Здравствуйте, GlebZ, Вы писали:

GZ>Знать бы что такое спецификации ООП. Вообще это очень сложная задача. Я бы сказал чрезвычайно сложная. Может потому за нее и не беруться как крупные так и мелкие компании. Но вполне возможная. Я по крайней мере не вижу никаких противопоказаний. SQL — работает же с функциями.


Лень заставляет говорить меня следующие вещи:

я не думаю, что нужно реализовывать подмножество какого-то там языка. если уж язык управляемый, то стоит использовать именно его самого, а не имитацию. существуют permissions на код. код должен исполняться на сервере. известна проблема полиморфности. поднимать объекты из базы при выборке — страшные тормоза. значит нужно хранить объекты в памяти.

я тоже думаю, что OODB обязана быть сервером приложений. для этого нужно реализовать транзакции на уровне оперативной памяти. т.к. всё очень лень, мне кажется лучше дописать mono'вский jitter для этих вещей.

IMHO одни C# с VB.NET сразу покроют процентов 10 пользователей базами данных.

GZ>С уважением, Gleb.
Re[4]: Объектные базы как они есть
От: vdimas Россия  
Дата: 07.04.05 23:12
Оценка:
Здравствуйте, GlebZ, Вы писали:

хорошо написано, осталось вспомнить, откуда вообще есть пошли СУБД. Именно оттуда, что внешняя память имеет ограничено-произвольный доступ, скорее даже местами последовательный...

СУБД — это ср-во хранения больших объемов данных на ВНЕШНЕМ носителе таким образом, чтобы обеспечивать быстое извлечение необходимых данных в оперативную память. Для организации этого мы используем ЛОГИЧЕСКОЕ проедставление данных, ключи, индексы (уменьшающие размер ВНЕШНЕЙ памяти, требуемый для поиска) и пр.

Берем ООП. В "живой" ООП программе в памяти "нанизаны" километры кружевов и макраме из ФИЗИЧЕСКИХ связей объектов опять же произвольной ФИЗИЧЕСКОЙ структуры. Соответственно, для эффективной работы ООП-ориентированных программ нужна память с абсолютно произвольным доступом.

Вполне возможно, что в какой-то момент времени в выч. системах оперативная память будет:
а) обладать персистентностью (типа flash).
б) быть "необходимого" размера.

Тогда ООП-хранилища и "покажут" этой реляционке, с ее суррогатными ключами и индексами.


------------
Как неплохую полумеру, я бы рассмотрел пока надежный движок РСУБД, который можно было бы ембеддить прямо в свою программу. Причем, открыть доступ к данным не только посредством SQL-запросов, но и для обычного алгоритмического сканирования и обработки. Да, тут уже за эффективность "плана" запроса будет отвечать сам программист, однако при наличии очень большого радиуса кривизны рук, можно получить весьма эффективную систему, сочетающую все, что нужно сочетать...

я бы не отказался в коде писать нечто (некий С++ — подобный язык, например):
[key<number>]
[persist]
struct MyDocRow : DbRow {
    int number;

    [index(SortAsc)]
    date docDate;

    int state;
};

[persist]
struct MyDocDetail : DbRow {
    refRow<MyDocRow> doc;
    
    money rowSum;
};


bool filter1(MyDocRow& docRow) { return state==5; };

struct filter2 {
   money threshold;
   filter2(money threshold) {this.threshold = threshold; }
   bool operator()(MyDocDetail& docDetail) { return rowSum>=threshold; }
}

[...]

struct DocSums : TmpRow {
    int docNumber;
    money docSum;    

    static Calculate(MyDocRow& docRow, Enumerator<MyDocDetail> detail) {
        docNumber = row.number;
        docSum = agregate_sum<MyDocDetail::rowSum>(detail);
    }
}

// целевой алгоритм
Enumerator<DocSums> GetDocSums(money threshold, date date1, date date2) {
    Enumerator<MyDocRow> docEnumerator = sort<MyDocRow::number, SortAsc>(seek(ByIndex<MyDocRow::docDate>(date1, date2)), filter1);
    NestedEnumerator<MyDocRow, MyDocDetail> docWithDetailEnumerator = join<MyDocDetail::doc>(docEnumerator, filter2(threshold));

    return transform<DocSums>(docWithDetailEnumerator, DocSums::Calculate);
}
Re[5]: Объектные базы как они есть
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 08.04.05 04:02
Оценка:
Здравствуйте, vdimas, Вы писали:

V>СУБД — это ср-во хранения больших объемов данных на ВНЕШНЕМ носителе таким образом, чтобы обеспечивать быстое извлечение необходимых данных в оперативную память. Для организации этого мы используем ЛОГИЧЕСКОЕ проедставление данных, ключи, индексы (уменьшающие размер ВНЕШНЕЙ памяти, требуемый для поиска) и пр.


Как раз физическая организация логических данных на диске + индексы серьезно УВЕЛИЧИВАЮТ объем внешней памяти, необходимый для хранения данных


V>------------

V>Как неплохую полумеру, я бы рассмотрел пока надежный движок РСУБД, который можно было бы ембеддить прямо в свою программу. Причем, открыть доступ к данным не только посредством SQL-запросов, но и для обычного алгоритмического сканирования и обработки. Да, тут уже за эффективность "плана" запроса будет отвечать сам программист, однако при наличии очень большого радиуса кривизны рук, можно получить весьма эффективную систему, сочетающую все, что нужно сочетать...

По-моему, есть такие готовые ООСУБД.

V>я бы не отказался в коде писать нечто (некий С++ — подобный язык, например):


Что-то похожее на то, что ты описал, поддерживали ООСУБД, в которых была поддержка C++. Насколько мне помниться, похожие возможности предоставлял POET (в последствии FastObjects).
... << RSDN@Home 1.1.4 beta 4 rev. 303>>


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.