ООБД - Философия программирования

shuklin wrote:
> От так я вам тут все свои ноу хау и выдал )) На данный момент из ноу хау
> реализована и опубликована новая версия идентификации экземпляров
> объектов, не совместимая с ODMG. Это я про синонимию и омонимию
> идентификаторов экземпляров объектов.
Ну так покажите результаты тестов. Какие проблемы?

>
>
> C>Интересны базовые алгоритмы — они определяют скорость работы. У вас
> есть что-то новое, чего нет в существующих ОО/РБД?
> Ну вот идентификация другая. Дальше будет больше но не сразу. Не
> реализованные фичи я обсуждать не буду.
Идентификации объектов в БД используются следующие:
1. Физический ID (ID объекта является физическим указателем на
расположение объекта в хранилище).
2. Логический ID, для преобразования в физическую позицию используется
какой-нибудь механизм типа каталога страниц.
Недостатки и преимущества обоих типов давно известны и хорошо описаны.

Что у вас нового?

> C>Если нет полиморфизма, то ОО "легким движением руки" превращается в РБД.
> РБД это в первую очередь РМД. А вот моя ОБД лежит на сетевой МД. РБД она
> не может быть ну никак.
Чистая сетевая модель не позволяет эффективно строить индексы, либо
требует фиксированные пути доступа к данным (что еще хуже).

Если мы начинаем строить индексы — то опять сваливаемся в РБД.

Кстати, эмуляции сетевых моделей с помощью РБД делаются без проблем —
просто считаем главный ключ записи указателем объекта. Коллекции
1-ко-многим делаются с помощью обратных указателей, а многие-ко-многим
делаются с помощью вспомогательной таблицы.

Ассимптотика у алгоритмов получается другая, но зато мы можем делать
ad-hoc запросы.

> C>Отличительная особенность ООБД — навигационный доступ. Благодаря нему
> можно легко обрабатывать сложносвязные данные, но как раз навигационный
> доступ мешает построению индексов.
> В РБД есть понятие буукмарк. Это и есть скрыты ОИД. Не понятно кому и
> чем ОИД мешает, в ОБД если он не мешает в РБД,
OID — это далеко не главная вещь. Я бы даже сказал, что второстепенная.

В РБД идентификатором объекта является главный ключ, и поиск по главному
ключу занимает O(log N) времени. При реальных объемах данных можно
считать, что он займет O(1) (амортизированое константное время).

Точка разлома — в представлении коллекций. В сетевых БД коллекции
хранятся непосредственно в объекте, то есть НЕ являются табличными данными.

Возьмем классический пример: есть список школ, у каждой школы список
учеников. Нам надо найти все школы с номерами от 20 до 100 и выбрать
всех учеников с 5 по 8 классы.

В случае РБД мы делаем выборку из таблицы школ по диапазону номеров
(O(log N) времени) и join'им ее с результатами выборки из школ по классу
ученика (тоже O(log N) времени). В результате, имеем ассимптотику O(log
N) для поиска.

В случае сетевой БД мы сначала получаем список школ с указанным номером
— это займет O(log N), если есть индекс по полю записи и O(N) в
противном случае. Затем мы для каждой найденной школы берем _весь_
список ее учеников и ищем в нем учеников с указаным возрастом. В общем,
имеем сложность O(log N)*O(log M), а при третьем уровне вложенности все
еще хуже — O(log N)*O(log M)*O(log K).

Можно схитрить — построить для некоторых путей доступа быстрые
lookup-таблицы. Именно это вы и делаете по намекам на HANDLE объекта,
различный в разных контекстах и волновое распространение изменений
(кстати, об этом еще в 70-х догадались

).

Но проблема появится при изменении схемы данных — это будет дорогая
операция, требующая прочитать уйму данных.

Posted via RSDN NNTP Server 2.0

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

C>Ну так покажите результаты тестов. Какие проблемы?

Никаких. вот домашняя страница проекта. Там даже сырцы открыты: http://www.shuklin.com/ai/ht/ru/cerebrum

Скорость сканирования C# объектов в кэш — до 80000 шт/сек
Скорость инстанциирования C# — ок 1000 шт/сек.

Второй показатель поддается относительно простой оптимизации. Первый — оптимизировать дальше будет гоораздо сложнее.

C>Идентификации объектов в БД используются следующие:
C>1. Физический ID (ID объекта является физическим указателем на
C>расположение объекта в хранилище).
C>2. Логический ID, для преобразования в физическую позицию используется
C>какой-нибудь механизм типа каталога страниц.
C>Недостатки и преимущества обоих типов давно известны и хорошо описаны.

C>Что у вас нового?

один и тот же ИД указывает одновременно на несколько разных объектов.

C>Чистая сетевая модель не позволяет эффективно строить индексы, либо
C>требует фиксированные пути доступа к данным (что еще хуже).

У меня сетевая модель с прямым доступам к узлам по их ИД, Так что индексы строить можно. Хотя в текущей версии они не реализованны.

C>Если мы начинаем строить индексы — то опять сваливаемся в РБД.

В БД похожую во многом на РБД. Вот только с РМД она совместимой не будет, значит и не РБД.

C>Кстати, эмуляции сетевых моделей с помощью РБД делаются без проблем —
C>просто считаем главный ключ записи указателем объекта. Коллекции
C>1-ко-многим делаются с помощью обратных указателей, а многие-ко-многим
C>делаются с помощью вспомогательной таблицы.

Разве без проблем? А перформанс? А удобство? ...

C>Ассимптотика у алгоритмов получается другая, но зато мы можем делать
C>ad-hoc запросы.

В сетевой БД никакая теория этого тоже не запрещает. LINQ видели?

>> C>Отличительная особенность ООБД — навигационный доступ. Благодаря нему
>> можно легко обрабатывать сложносвязные данные, но как раз навигационный
>> доступ мешает построению индексов.
>> В РБД есть понятие буукмарк. Это и есть скрыты ОИД. Не понятно кому и
>> чем ОИД мешает, в ОБД если он не мешает в РБД,
C>OID — это далеко не главная вещь. Я бы даже сказал, что второстепенная.

Тогда не вижу сути вопроса. В РБД тоже есть скрытый навигационный доступ, и он нормально соседсвует с индексами, мало того этими же индексами и используется.

C>В РБД идентификатором объекта является главный ключ, и поиск по главному
C>ключу занимает O(log N) времени. При реальных объемах данных можно
C>считать, что он займет O(1) (амортизированое константное время).

Да. Но накладные расходы на инстанциирование в ОРМ больше чем у ОБД. А так все действительно ооочень близко и похоже.

C>Точка разлома — в представлении коллекций. В сетевых БД коллекции
C>хранятся непосредственно в объекте, то есть НЕ являются табличными данными.

Именно. В сетевой ОБД ваще все не является табличными данными. В этом тоже дополнительное отличие. И с моей точки зрения доп приемущество. А механизмы реализации — само собой теже. Теже индексы, страницы, транзакции, блокировки, версии ...

C>Возьмем классический пример: есть список школ, у каждой школы список
C>учеников. Нам надо найти все школы с номерами от 20 до 100 и выбрать
C>всех учеников с 5 по 8 классы.

C>В случае РБД мы делаем выборку из таблицы школ по диапазону номеров
C>(O(log N) времени) и join'им ее с результатами выборки из школ по классу
C>ученика (тоже O(log N) времени). В результате, имеем ассимптотику O(log
C>N) для поиска.

Мне вот что тут интересно, JOIN у вас в этом примере оказался O(1).
Имхо тут будет тот же O(logN) * O(logN). Если есть способ это обойти — буду благодарен за повышение квалификации.
Я тогда этот метод спианерю у РБД и применю у себя.

Давайте здесь более подробно. Пусть Ш — общее число школ. У — общее число учеников. Ш' — число отфильтрованных школ. У' — число отфильтрованных учеников.

тогда поиск в РБД будет O(logШ + logУ + log(Ш'*У'))
с другой стороны в каждой школе учатся вовсе не все ученики. тоесть у — это уже среднее число учеников в каждой школе — чтоб не заморачиваться.

поиск в ОБД O(logШ + logШ' * logу)

шото мне кажется, что ОБД здесь уделала РБД, даже при тупом обходе дерева в глубь.

Давайте это разберем — в натуре интересно и полезно.

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

S>Я уже устал отвечать на этот вопрос одно и тоже. Не рекомендую — не значит не могу. Могу. Но инкапсуляция в том виде в котором она есть в обычном языке программирования в БД лишня. Она лишняя в РБД. Она лишняя в ОБД, Не нужна там такая концепция. Лишняя концепция не значит нереализуемая или неподдреживаемая. Я ее поддерживаю. Кто пользуется — принимает на себя следствия ее использования. Согласитесь, если сама концепция инкапсуляции просто по законам логики влечет за собой отрицательные последствия для БД — не зависимо от того ОБД или РБД — то наверное что то не с конкретной реализацией ОБД а с самой концепцией. Вот я и дал возможность — кому надо — пользоваться, кому не надо — не пользоваться.

Я могу лишь сказать, что то что вы не можете реализовать без проблем инкапсуляцию это потому, что вы плохо подумали, а не потому что это невозможно. И не надо говорить про логику — это слишком громкое заявление. Поэтому решение ваше половинчато. А говорить что инкапсуляция не нужна это вообще критическая ошибка. Инкапсуляция позволяет говорить об объектах. Если ее нет — это не объекты. Более того смысл инкапсуляции очевиден и доказан. Вы же с этим спорите и говорите, что тут что-то не то с концепцией...

IT>>А как же внутреннее состояние объекта. Жесткие требования к сериализации как я понимаю тоже из этой серии. То что будет сериализоваться будет лежать в базе просто как блоб, поиска по этим данных мы не получим.

S>Тоже устал писать одно и тоже. Объект в моей БД можно сохранять частями. См. в соседних ветках.

Это тоже не объект. Пока вы продолжаете называть ваши необъектные данные объектами вы продолжаете натыкаться на теже самые вопросы и комментарии. Нечему тут удивляться и вздыхать — устали, отдохните.

Понятие объекта в ООП строго. Брать от него половину и говорить, что это вот мол у меня тоже объект — оснований быть не может.

S>Знаете, для меня лучший аргумент — это работоспособный код который решает описанные проблемы. В соседних ветках уже есть гора сообщений с кратким описанием решений. Этот работоспособный код у меня есть, так что можете тут хоть лопнуть — мне это как бы без разницы.

Работоспособный код в вашем понимании это вообще не аргумент. Можно все что угодно сделать работоспособного...
На вашей так называемой "ОБД" есть реально работающие крупные системы в промышленной эксплуатации с опытом хотя бы в 1 год?
Хоть 1? Приведите пример.