_vovin пишет:
>> Это покрывает только тривиальные случаи типа "age>23 and height>180". >> Как декомпилировать и осмыслить сложный запрос с join'ами (которые в ИЯ >> превратятся в циклы) — мне непонятно. > Даже упомянутый случай с GLORP-ом отлично решает эту проблему. > Построенное синтаксическое дерево исходного языка (некоторого > подмножества) отображается на SQL и дальше выполняется обычный запрос.
В доке на Restore я вижу только простенькие примеры типа "allPersons
select: [ :each | each dateOfBirth year = 1970]." Чего-то сложного я там
не вижу.
Тот же Hinernate с HQL покрывает _значительно_ большую функциональность.
И при этом реально работает.
> Это уже пройденный этап. А главная проблема связана с полиморфизмом.
А в чем с нима проблема? Он замечательно ложится на RDB.
Здравствуйте, 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 не станешь искать школьников при помощи курсора? Вот и тут — воспользуемся тем фактом, что мы ищем учеников любой школы:
Оптимизатор будет вполне способен увидеть здесь join.
C>Для случая RDB такой алгоритм будет работать O(n) без индексов и O(log C>n) с индексами.
Гм. n — это что?
C>Если его соптимизировать в его ОО-воплощении, то получится опять тот же C>реляционный алгоритм.
Естественно! Цель как раз в том и состоит, чтобы получить алгоритм, близкий к реляционному. Только без ручного затачивания под конкретные реализации, с поддержкой полиморфизма и инкапсуляции. В нормальной системе запрос, который ты хотел написать, будет вообще выглядеть примерно так:
Здравствуйте, Alexey Rovdo, Вы писали:
AR>Мне кажется, что производители коммерческих продуктов берутся за все это только по одной причине — желание соответствовать как можно большему числу стандартов. Проприетарные решения не в чести у покупателей, а альтернативы у ODMG пока нет (хотя бурное развитие JDO можно рассматривать как заявку — и этот путь, полагаю, более верен, чем путь ODMG).
Поэтому и процветают ORM. У них нет понятия о стандартах, у них есть понятия об эффективности. В той степени которой они могут добиться. Тема ODMG уже надоела. Ну неживой он. Прошло столько времени с его создания. Они давно уже распустились. Зачем поддерживать то, чего уже практически нет.
GZ>>Запросы — это не столько получение некоторого набора объектов, а еще инструмент выполнения некоторых действий на некоторым множеством объектов.
AR>Действительно, групповые операции над данными вообще не предусмотрены никакими спецификациями ООП (по крайней мере я таких не знаю). Как результат, производители вынуждены придумывать свои проприетарные решения. Так, к примеру, в ООСУБД VDS есть некоторые рудиментарные средства, но вот в JDO вроде пока ничего такого ...
Знать бы что такое спецификации ООП. Вообще это очень сложная задача. Я бы сказал чрезвычайно сложная. Может потому за нее и не беруться как крупные так и мелкие компании. Но вполне возможная. Я по крайней мере не вижу никаких противопоказаний. SQL — работает же с функциями.
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. >
Sinclair пишет:
> C>Тогда непонятно ЧЕМ же OODB отличается от RDB. > Тем, что в RDB нет инкапсуляции, наследования и полиморфизма.
В хранилище ООБД инкапсюляции нет, как и в RDB. Наследование и
полиморфизм замечательно выражаются в RDB в виде объединенных по PK
таблиц (возможно с полями-дискриминаторами).
То есть на практике объектные модели (за исключением самых извращенных)
вполне прилично ложатся в RDB.
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.
Здравствуйте, Cyberax, Вы писали:
C>Sinclair пишет:
>> C>Тогда непонятно ЧЕМ же OODB отличается от RDB. >> Тем, что в RDB нет инкапсуляции, наследования и полиморфизма.
C>В хранилище ООБД инкапсюляции нет, как и в RDB.
В хранилище нет. В ООDB да. В хранилище ООБД только состояние объектов. C>Наследование и C>полиморфизм замечательно выражаются в RDB в виде объединенных по PK C>таблиц (возможно с полями-дискриминаторами).
Это всего лишь один из самых простых и самых неэффективных способов маппирования объектов в RDBMS.
C>То есть на практике объектные модели (за исключением самых извращенных) C>вполне прилично ложатся в RDB.
Ну почти да. Только для этого нужно очень много дописать. И учитывая удаленность хранилища и самой системы эффективности достойной ООДБ ты точно не получишь
Здравствуйте, Cyberax, Вы писали: C>В хранилище ООБД инкапсюляции нет, как и в RDB. C> Наследование и полиморфизм замечательно выражаются в RDB в виде объединенных по PK C>таблиц (возможно с полями-дискриминаторами).
Существующие решения никакого полиморфизма не предоставляют. C>вполне прилично ложатся в RDB.
Нормальный полиморфизм ты в RDB запаришься складывать. Точнее, внесение малейших изменений потребует перетряхивания значительной части схемы.
... << RSDN@Home 1.1.4 beta 4 rev. 347>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Cyberax пишет: > То есть на практике объектные модели (за исключением самых извращенных) > вполне прилично ложатся в RDB.
В репозитории для VW ST лежит пакет позволяющий сохранить любой объект в
БД без написания мапов. Задействовано вроде 6 таблиц (не помню точно).
Думаю для java сделать такое — тоже без проблем.
--
Andrei N.Sobchuck
JabberID: andreis@jabber.ru. ICQ UIN: 46466235.
[скипнуто в знак согласия]
Именно. А теперь представь себе, над одним и тем-же состоянием работают несколько отделов. Любое изменение должно быть состояния должно изменить код каждого из них. Иногда не знаешь, что было изменение от разработчика за соседним компьютером, а тут вообще плохо. Нужна единая прокладка между состоянием и пользователя состояния.
Однако — ты предлагал накладывать несколько реализаций на одно и то же состояние.Re[4]: Объектные базы как они есть
Что меня и возмутило. Объект накладываемый на состояние — священная корова отвечающая за согласованность состояния. Грешно мучить эту корову. Всем придется плохо. А что будет сверху — делегирования, аггрегация, какие-то внешние сервисы... Это уже другой вопрос.
Здравствуйте, GlebZ, Вы писали:
GZ>Здравствуйте, eao197, Вы писали:
GZ>[скипнуто в знак согласия] GZ>Именно. А теперь представь себе, над одним и тем-же состоянием работают несколько отделов. Любое изменение должно быть состояния должно изменить код каждого из них. Иногда не знаешь, что было изменение от разработчика за соседним компьютером, а тут вообще плохо.
Для контроля изменений коллеги-разработчика применяются системы контроля версий
Мы, например, даже на боевые сервера системы устанавливаем через систему контроля версий
GZ> Нужна единая прокладка между состоянием и пользователя состояния.
А если серьезно, то здесь есть большая проблема, которая требует решения.
Причем для неуправляемого C++ это более серьезный вопрос, чем для управляемых языков/сред. Но и там так же могут быть проблемы. Например, если тянуть код объектов с сервера, то при изменении версии софта на сервере может потребоваться скачивать слишком большой объем кода. Даже если он и закэшируется на клиенте для последующего использования, то первоначальная загрузка может стать очень дорогой (особенно если с кодом объекта потянутся и его зависимости). Кроме того, как быть системам, которые работают в режиме 24x7? Делает клиент очередной запрос на сервер за объектом, а сервер ему и отвечает: дорогой, закачай-ка сначала мегабайт-другой нового кода, а затем я тебе объект отдам. За время этой закачки все транзакции данного клиента тихо по тайм-ауту умирают
Можно сделать как в случае с серверами приложений и тонким клиентом. Клиент только инициирует запрос, который реально выполняется на сервере, рядом с ООСУБД сервером. Но в этом случае обновление версии софта для сервера приложений является простой технической задачей. Даже для систем 24x7. Но такой подход вряд ли возможен для CAD систем.
Еще один подход состоит в том, чтобы сервер понимал версии клиентов. И умел проводить модификацию данных на лету. Т.е. изменилась схема данных на сервере, а объект запросил старый клиент, сервер отдал клиенту объект в старой схеме данных. Получил сервер от старого клиента объект -- преобразовал его к новому виду и сохранил в БД. Такой подход, как мне помниться, у Константина Книжника в Goods был реализован.
GZ>Однако — ты предлагал накладывать несколько реализаций на одно и то же состояние.Re[4]: Объектные базы как они есть
Что меня и возмутило. Объект накладываемый на состояние — священная корова отвечающая за согласованность состояния. Грешно мучить эту корову. Всем придется плохо. А что будет сверху — делегирования, аггрегация, какие-то внешние сервисы... Это уже другой вопрос.
Да, но хотелось бы, чтобы при извлечении объекта из БД не приходилось вручную агрегировать его в какой-то специфический прикладной объект. А то получится как с парсингом данных в XML -- поднимаем из XML DOM-дерево, пробегаем по нему и строим дерево нужных объектов для дальнейшей работы (тоже самое можно и с SAX парсингом делать). Вот этой лишней ручной работы не хотелось бы.
... << RSDN@Home 1.1.4 beta 4 rev. 303>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, 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++.
Здравствуйте, eao197, Вы писали:
GZ>> Нужна единая прокладка между состоянием и пользователя состояния.
E>А если серьезно, то здесь есть большая проблема, которая требует решения. E>Причем для неуправляемого C++ это более серьезный вопрос, чем для управляемых языков/сред. Но и там так же могут быть проблемы. Например, если тянуть код объектов с сервера, то при изменении версии софта на сервере может потребоваться скачивать слишком большой объем кода. Даже если он и закэшируется на клиенте для последующего использования, то первоначальная загрузка может стать очень дорогой (особенно если с кодом объекта потянутся и его зависимости). Кроме того, как быть системам, которые работают в режиме 24x7? Делает клиент очередной запрос на сервер за объектом, а сервер ему и отвечает: дорогой, закачай-ка сначала мегабайт-другой нового кода, а затем я тебе объект отдам. За время этой закачки все транзакции данного клиента тихо по тайм-ауту умирают
E>Можно сделать как в случае с серверами приложений и тонким клиентом. Клиент только инициирует запрос, который реально выполняется на сервере, рядом с ООСУБД сервером. Но в этом случае обновление версии софта для сервера приложений является простой технической задачей. Даже для систем 24x7. Но такой подход вряд ли возможен для CAD систем.
А для CAD важен 24x7(с ними не работал)?
E>Еще один подход состоит в том, чтобы сервер понимал версии клиентов. И умел проводить модификацию данных на лету. Т.е. изменилась схема данных на сервере, а объект запросил старый клиент, сервер отдал клиенту объект в старой схеме данных. Получил сервер от старого клиента объект -- преобразовал его к новому виду и сохранил в БД. Такой подход, как мне помниться, у Константина Книжника в Goods был реализован.
Вот именно поэтому есть полиформизм, инкапсуляция и интерфейсы.
Интерфейс — это некоторая соглашение того, что объект умеет делать какой-то набор действий. Напрямую ни схема данных хранилища ООБД, ни сами данные клиенту не доступны. Он может оперировать только интерфейсами. Реализация интерфейсов зависит от других людей. И если эти люди решили, что пользователю можно оставить старую версию интерфейса и сделать новую — то никаких особых проблем не существует.(главное не доводить это до маразма ActiveX). У меня системы именно по такому принципу действуют. При подключении на сервер имен, клиент дает свою версию. Ну и сервер имен отдает те интерфейсы которые могут работать с данной версией клиента.
E>Да, но хотелось бы, чтобы при извлечении объекта из БД не приходилось вручную агрегировать его в какой-то специфический прикладной объект. А то получится как с парсингом данных в XML -- поднимаем из XML DOM-дерево, пробегаем по нему и строим дерево нужных объектов для дальнейшей работы (тоже самое можно и с SAX парсингом делать). Вот этой лишней ручной работы не хотелось бы.
То есть, другими словами. В ООБД хранить не только бизнес-объекты, но и сервисные объекты. То есть, всю бизнес-логику. Которая знает о типах(а лучше, в силу вышеперечисленного, интерфейсы) друг, друга. Если я правильно тебя понял, то я только за. Единственно против чего я категорически против, ни одна сволочь не может добраться к состоянию объекта минуя единую реализацию объекта.
Здравствуйте, 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>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
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.
Здравствуйте, 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++.
Здравствуйте, GlebZ, Вы писали:
GZ>Знать бы что такое спецификации ООП. Вообще это очень сложная задача. Я бы сказал чрезвычайно сложная. Может потому за нее и не беруться как крупные так и мелкие компании. Но вполне возможная. Я по крайней мере не вижу никаких противопоказаний. SQL — работает же с функциями.
Лень заставляет говорить меня следующие вещи:
я не думаю, что нужно реализовывать подмножество какого-то там языка. если уж язык управляемый, то стоит использовать именно его самого, а не имитацию. существуют permissions на код. код должен исполняться на сервере. известна проблема полиморфности. поднимать объекты из базы при выборке — страшные тормоза. значит нужно хранить объекты в памяти.
я тоже думаю, что OODB обязана быть сервером приложений. для этого нужно реализовать транзакции на уровне оперативной памяти. т.к. всё очень лень, мне кажется лучше дописать mono'вский jitter для этих вещей.
IMHO одни C# с VB.NET сразу покроют процентов 10 пользователей базами данных.
GZ>С уважением, Gleb.
хорошо написано, осталось вспомнить, откуда вообще есть пошли СУБД. Именно оттуда, что внешняя память имеет ограничено-произвольный доступ, скорее даже местами последовательный...
СУБД — это ср-во хранения больших объемов данных на ВНЕШНЕМ носителе таким образом, чтобы обеспечивать быстое извлечение необходимых данных в оперативную память. Для организации этого мы используем ЛОГИЧЕСКОЕ проедставление данных, ключи, индексы (уменьшающие размер ВНЕШНЕЙ памяти, требуемый для поиска) и пр.
Берем ООП. В "живой" ООП программе в памяти "нанизаны" километры кружевов и макраме из ФИЗИЧЕСКИХ связей объектов опять же произвольной ФИЗИЧЕСКОЙ структуры. Соответственно, для эффективной работы ООП-ориентированных программ нужна память с абсолютно произвольным доступом.
Вполне возможно, что в какой-то момент времени в выч. системах оперативная память будет:
а) обладать персистентностью (типа flash).
б) быть "необходимого" размера.
Тогда ООП-хранилища и "покажут" этой реляционке, с ее суррогатными ключами и индексами.
------------
Как неплохую полумеру, я бы рассмотрел пока надежный движок РСУБД, который можно было бы ембеддить прямо в свою программу. Причем, открыть доступ к данным не только посредством SQL-запросов, но и для обычного алгоритмического сканирования и обработки. Да, тут уже за эффективность "плана" запроса будет отвечать сам программист, однако при наличии очень большого радиуса кривизны рук, можно получить весьма эффективную систему, сочетающую все, что нужно сочетать...
я бы не отказался в коде писать нечто (некий С++ — подобный язык, например):
Здравствуйте, vdimas, Вы писали:
V>СУБД — это ср-во хранения больших объемов данных на ВНЕШНЕМ носителе таким образом, чтобы обеспечивать быстое извлечение необходимых данных в оперативную память. Для организации этого мы используем ЛОГИЧЕСКОЕ проедставление данных, ключи, индексы (уменьшающие размер ВНЕШНЕЙ памяти, требуемый для поиска) и пр.
Как раз физическая организация логических данных на диске + индексы серьезно УВЕЛИЧИВАЮТ объем внешней памяти, необходимый для хранения данных
V>------------ V>Как неплохую полумеру, я бы рассмотрел пока надежный движок РСУБД, который можно было бы ембеддить прямо в свою программу. Причем, открыть доступ к данным не только посредством SQL-запросов, но и для обычного алгоритмического сканирования и обработки. Да, тут уже за эффективность "плана" запроса будет отвечать сам программист, однако при наличии очень большого радиуса кривизны рук, можно получить весьма эффективную систему, сочетающую все, что нужно сочетать...
По-моему, есть такие готовые ООСУБД.
V>я бы не отказался в коде писать нечто (некий С++ — подобный язык, например):
Что-то похожее на то, что ты описал, поддерживали ООСУБД, в которых была поддержка C++. Насколько мне помниться, похожие возможности предоставлял POET (в последствии FastObjects).
... << RSDN@Home 1.1.4 beta 4 rev. 303>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.