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

GZ>здесь

Автор: GlebZ
Дата: 05.04.05

. Тогда тоже была весна(очевидно ООБД — это весеннее обострение).

весной всем хочется секса, и только у программистов это проявляется в такой странной форме

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

S> Какие здесь подводные камни?
Основной подводный камень — сделать все на основе ООБД. В самом понятии ООБД содержится некая ущербность. Дело в том, что ОО — это не голые данные, а прежде всего поведение. Иными словами ОО это некоторая обертка над данными, которая навязывает этим данным определенное поведение.
Таким образом, предлагая хранить объекты, ты предлагаешь хранить определенное поведение, что как минимум довольно здорово ограничивает возможности самих данных. Все бы ничего, если бы речь шла о какой-то конкретной довольно узкой задаче, в некоторых случаях для ООБД еще можно найти уместное применение, однако ОС система довольно эклектичная и там живут данные самого разного назначения. И основное свойство данных заключается в том, что жизненный цикл самих данных гораздо больше, чем жизненный цикл некоего поведения навязанного этим данным в рамках определенной системы. Отсюда следует, что даже если на начальном этапе все замечательно, то никто не даст гарантии, что со временем семантика данных не изменится, и при тех же циферках данным не понадобится навязать другое поведение, что будет сделать довольно проблематично, если хранить данные не в чистом виде, а уже обернутыми в некоторую семантическую модель.
Примерно такие же соображения излагал и Кодд, когда проталкивал реляционную теорию для БД общего назначения.
Сейчас с успехом пользуются данными кропотливо вносимыми с семидесятых годов, за это время они перекочевали через нескольких поколений хранилищ и пережили сотни способов интерпретации, и вряд ли это было бы возможным если бы в самом начале использовались объектные хранилища или даже иерархические.
Из вышеказанного следует, что для систем с высокой степенью изменчивости и большим количеством разнородных данных, к которым относится и ОС, ООБД в чистом виде — не подходят.

Здравствуйте, Дарней, Вы писали:
Это заблуждение.
Реляционные данные — это записи о фактах. Тем они и хороши, что факты никак не меняются со временем. Десятого мая 1966 года Дж.Виллис купил в бакалейном отделе молока на 0.52 доллара. Алгоритмы обработки — вещь эфемерная. В 1966 году просто никто не знал, что делать со всеми этими Дж.Виллисами. Потом были придуманы всякие отчеты с группировками для того, чтобы сэйлзы из сети Таргет заявляли "нам нужно увеличивать расфасовку молочных продуктов, потому что на мелкую падает спрос". И показывали различные тренды.
Уже потом вопрос "а что с этим делать" стали называть Data Mining, защищать на этом диссертации и делать большие деньги.
От этого факты не перестали быть фактами.
Хранимые процедуры, триггеры — это все фуфло. Это попытка научить RDBMS вести себя как сервер приложений. В то время, как ее изначальная роль — только регистрировать факты.
Именно поэтому инкапсуляция поведения в DBMS — это путь к потере вот этой независимой составляющей. Никто не говорит о том, что это вообще тупик. Но некоторые данные про урожай риса пережили падение пирамид; в то время, как от методов их обработки ничего не осталось.

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

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

S>>>Ваши доводы или совершенно неубедительны,
M>>Аргументы кончились? Не нравится — не ешь..

S>Извините, но у Вас я вообще аргументов не заметил. Только декларацию того что ОБД это бесперспективно. "Не нравится — не ешь.. "

S>Ну не любишь ты ОБД, а я не люблю РБД хоть и работаю с РБД каждый день, и каждый день по сравнению со своей БД не люблю SQL все больше и больше . Знаешь, мне с тобой беседовать просто скушно. Ничего нового ты не пишешь, только твердишь что ОБД — фигня. Ни на один мой тезис о внутреннем устройсве Cerebrum ты не ответил. Ни о синонимии/омонимии идентификаторов, ни о структурном полиморфизме ... Какие еще аргументы? , ты б в старые врубился хоть Так. С вами я флейм заканчиваю. Меняйте ник и стиль общения. Жалко на такое время тратить.

Merle тебя разводит по понятиям.
Базданщики это такая кагорта программеров, которые так любили стратигическое планирование, что съели много дерьма пока проектировали свои базы. Теперь это дерьмо лезет наружу. Это выражается в снобизме на понятиях. Прямо как в академии наук. Они убеждены в том, что если ты не ел тогоже дерьма то и ничего хорошего сделать не сможешь. И нечего смотреть на твои поделки. Ты в их глазах — безграмотный самоучка, выскочка. Над которым можно разве что поглумиться.
Merle, ничего личного. Это просто психология и национальное самосознание такие.

А вам, shuklin — совет. Ищите спонсора среди буржуев. У нас в россии не принято делать из человека икону при жизни.
Вот когда сдохнет — пожалуйста.
А так мы в россии всяких надоедливых самоучек-выскочек только травим да глумимся над ними.

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

S>>Ваши доводы или совершенно неубедительны,
M>Аргументы кончились? Не нравится — не ешь..

Извините, но у Вас я вообще аргументов не заметил. Только декларацию того что ОБД это бесперспективно. "Не нравится — не ешь.. "

Ну не любишь ты ОБД, а я не люблю РБД хоть и работаю с РБД каждый день, и каждый день по сравнению со своей БД не люблю SQL все больше и больше . Знаешь, мне с тобой беседовать просто скушно. Ничего нового ты не пишешь, только твердишь что ОБД — фигня. Ни на один мой тезис о внутреннем устройсве Cerebrum ты не ответил. Ни о синонимии/омонимии идентификаторов, ни о структурном полиморфизме ... Какие еще аргументы? , ты б в старые врубился хоть Так. С вами я флейм заканчиваю. Меняйте ник и стиль общения. Жалко на такое время тратить.

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

S>От так я вам тут все свои ноу хау и выдал ))

Пора тему сворачивать. Это уже начинает походить на анекдот про Неуловимого Джо.

Здравствуйте, shuklin, Вы писали:
S>Аналогично. В отличие от педантов, для которых секурити (инкапсуляция) важнее функциональности, я считаю основным достоинством ООП полиморфизм. А вот его то я поддерживаю в своей БД максимально.
Ты не можешь поддерживать полиморфизм, не поддерживая инкапсуляции. Поддержка полиморфизма требует развязки интерфейса и его реализации, а при отсутствии инкапсуляции это невозможно. Слишком велико будет искушение писать внешний код (хотя бы те же запросы) в терминах публичных полей, а не виртуальных методов/свойств. Вот тебе и весь полиморфизм — нельзя будет поменять реализации этих методов/свойств, т.к. есть внешний код, завязанный на внутреннее устройство объекта.

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-х догадались ).

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

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

S>Да. Но накладные расходы на инстанциирование в ОРМ больше чем у ОБД. А так все действительно ооочень близко и похоже.
А вот теперь я тебя расстрою: накладными расходами на инстанцирование можно пренебречь. Вообще.
По сравнению со стоимостью поднятия 64kb с диска в память, самый медленный алгоритм конверсии этих килобайт в объекты бесконечно быстр.
Насчет "вся БД в памяти" — типичные реализации ODBMS выполняют "подмену адресов", благодаря которой стоимость dereferencing уже загруженного объекта близка к стоимости процессорной команды косвенного доступа. На фоне этого 80000 ссылок в секунду на 1.7 Mhz — это просто тихий ужас.

Оптимизировать инстанцирование имеет смысл только для систем, где запросы выполняются полным перебором. Но это сродни попыткам научиться быстрее вычерпывать воду из дырявой лодки. Если удастся найти метод, позволяющий вместо 8000 тысяч страниц читать ровно 1 — ту, на которой расположен искомый объект, в сэкономленное время можно вдосталь позаниматься неспешным инстанцированием.

S>Мне вот что тут интересно, JOIN у вас в этом примере оказался O(1).
Рекомендую поискать литературу по построению СУБД.
S>Давайте здесь более подробно. Пусть Ш — общее число школ. У — общее число учеников. Ш' — число отфильтрованных школ. У' — число отфильтрованных учеников.

S>тогда поиск в РБД будет O(logШ + logУ + log(Ш'*У'))
S>поиск в ОБД O(logШ + logШ' * logу)
А куда у нас делся поиск школ? С чего он вдруг стал log(Ш)? Или у нас индекс есть? Почему у нас стоимость поиска учеников внутри школы стала logу?
Ок, давайте сравним.
РБД: O(logШ + logУ + log(Ш')+log(У'))
ОБД: O(logШ + logУ + log(Ш')*log(y))
Сравнивать, очевидно, надо log(Ш')+log(У') и log(Ш')*log(y).

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

S>Давайте это разберем — в натуре интересно и полезно.
Давайте подставим числа. Допустим, Ш=1000, Ш' = 80 (номера от 20 до 100). y = 2000 (Y=y*Ш= 2000000) ; при этом Y' = 40% от общего количества всех учеников = 800000 (классы 5, 6, 7 и 8).
для РБД мы получаем log(80)+log(800000) = 4.38 + 13.59 ~ 18.
Для ОБД — 4.38*7.60 ~ 33.3
И кто тут кого уделал? (Логарифмы везде натуральные).

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

GZ>>Что значит привинчен?
AVK>То и значит, что в ООБД данные неразрывно связаны с кодом.
Вообще-то наоборот, и зависит от типа OODB. Фактически существует два типа OODB — пассивные, и активные. Пассивные, типа того-же Versant, отличаются от OODB+ORM мало. Единственное, что хранилище максимально приспособлено под навигационный доступ. Декларативные запросы идут не по объектам, а именно по данным. Активные, типа GemStone более объектные и полностью инкапсулируют данные. Правда иногда все равно эту инкапсуляцию нарушают на уровне запросов(к сожалению не спец по ней, сужу по рассказам).
Основная проблема того, что нарушается инкапсуляция — многоязычность и императивность языков. Запрос должен быть переформирован в форму которая должна быть максимально селективна. Для императива, в котором может быть написано все что угодно, из кода которого иногда просто невозможно получить граф это принципиально невозможно. Microsoft поступил проще введя лямбды. Возможно под это дело появятся новые ODB.

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

GZ>>А может стоит тут интерпретировать не как объекты OODB, а именно как объекты из компоненты OODB?
S>Че-то не улавливаю. Ты не мог бы развернуть?
Легко сказать да трудно сделать. Страдаю глобализмом. Все нижеследуещее следует считать во первых IMHO, во вторых относящимся именно к объектно-ориентированным базам а никак иначе. Вопросы навигации не рассматриваю.
Итак. Прежде всего некоторые тезисы. Тезисы по поводу РСУБД, касаются именно именно идеальной реляционки времен Кодда и SystemR. Кое что было решенов рамках СУБД, кое что с помощью сервисов поставляемые с той, или иной базой данных.
1. Недостаток РСУБД. Скудность информации данных. Зачастую о смысле данных можно узнать только перерыв приложение которое его использует.
2. Недостаток РСУБД. Недостаточная эффективность реляционной модели. Вряд ли что эффективней работает на строгоструктурированными данными чем РСУБД, но так как мы имеем данные огромного объема даже этого механизма не хватает. В ответ на это появились вычислимые поля на триггерах, материализованные вьюхи, временные таблицы и прочая лабуда.
3. Недостаток РСУБД. Даже для задачи хранения и получения данных, нужны вычисления. А для вычислений нужен язык. В РСУБД были внедрены языки, но поскольку первичная их задача — доступ к данным. На вычислительную мощность, и, в большей степени, на удобство пользования разработчики положили.
4. Недостаток РСУБД. Недостаточность инкапсуляции. Вьюхи в классическом виде не выполняют своей роли полностью так как работают на чтение. На данный момент можно пользовать stored procedure, которую нельзя включить в custom SQL запрос. Или с помощью триггеров instead of навешанную на VIEW или Table. Еще в некоторых базах существуют функции(сразу признаюсь что не знаю, используются они в оптимизации запросов, или нет).
5. Недостаток OOСУБД. Инкапсуляция. Инкапсуляция хороша от внешних злодеев, и очень вредна внутри OOСУБД. Наибольший пострадавший в данном случае — оптимизатор запросов.
6. Недостаток OOСУБД. Слишком сильная привязанность к таблицам и месту хранения. Во многом это усуглубляет недостаток РСУБД из пункта 2 полученный в наследство. Даже скажу, очень сильно усуглубляет.
7. Недостаток OOСУБД. Объект который имеет состояние, и управляет им тяжел и неудобен в сопровождении. После того, как я перестал использовать в бизнес-объектах функционал реализующий работу с их состоянием, чессно-слово, обрел нирвану. Поэтому желательно разделение бизнес-объекта и бизнес-сервиса. Таким образом это улучшает сопровождаемость кода.
8. Принцип Деметры(принцип хорошего проектирования):

Для любого класса C и для любого метода M, связанного с C, все объекты, которым M посылает сообщение, должны быть экземплярами классов, ассоциированными со следующими классами: классами аргументов M (включая C); классами переменных экземпляра C.

Взято отсюда.здесь. Интересная статья, советую прочитать.
9. Предыдущий пункт сильно противоречит ad-hoc запросам в РСУБД в которых ты можешь взять любую таблицу, и сджоинить с любой другой таблицей. Правда при этом надо учитывать фактор индексов, без которых данная операция будет безбожно тормозить.
9. Все что можно уже выдумано до нас. В частности компонентность и модификаторы компонентности.
10. Все что можно уже выдумано до нас. В частности версионификация. Объекты легко адаптируют в компонентной программе сразу для нескольких клиентов.
11. SQL хотя не является процедурным языком, но также не является и функциональным, так как не поддерживает рекурсию. Соответсвенно на нем нельзя строить произвольно сложные запросы.
12. Недостаток OODB. Он пытается увеличить скорость навигационных запросов путем адаптации хранилища к ним. Он сознательно адаптирует хранилище под конкретное приложение согласно объектной схеме. (Это я намекаю на хранение подчиненных коллекций и объектов вместе с объектом владельцем). Соответвенно теряется эффективность ad-hoc запросов.
12. Для оптимизатора запросов важна подробная информация.


Итак вооружившись этими тезисами, начинаю сочинять(играю как умею, в пианиста не стрелять).
Для каждого вида бизнес-объектов строится пара — объект состояния(хранящий состояние), и объект доступа(выполняющий операции связанные с данным объектом состояния).
Объект состояния.
1. Он только предоставляет интерфейс доступа к состоянию. Реализация доступна только в самой сборке.
2. Объект зависит от заказываемой версии. То есть, одна и та же таблица или результат может быть инстанцирована несколькими объектами в зависимости от заказываемой версии.
3. Таблица всегда содержит объекты последней версии. Объект может быть не инстанцирован никогда, и его задача только в описании метаданных для таблицы.
4. Объект содержащий данные может быть не виден за пределами сервера OODB, и использоваться только внутри ее.
5. Объект состояния может быть не привязан к таблице, и использоваться только для сборки внутри сервера, и отправки состояния клиенту.(для аналога view)
6. Объект в силу пункта 2(версионификация), может быть собран через кодогенерацию(для метапрограммирования мешает режим 24x7).
7. Объект должен быть настолько прост, насколько он может показывать свое состояние, и содержать элементарные бизнес-правила(аналог check).

Объект доступа.
1. Основная его задача не получить или изменить объект. Основная его задача указать менеджеру запросов как преобразовать запрос для использования данного типа объектов.
2. Объект может передавать управления другим объектам доступа(для реализации аналога view).
3. Объект должен поддерживать инстанцирование и разбор объектов всех версий.
4. Объект должен поддерживать версионификацию по комовскому типу. Например, показывать только свой интерфейс, который в свою очередь зависит от заказываемой версии запроса. И обрабатывать запрос в свою очередь согласно заказанной версии.
5. Все методы объекта должны быть функциональными. Это важно для оптимизатора запросов. На входе граф запроса и контекст выполнения, на выходе трансформированный граф запроса и контекст.
6. Методы получения объектов состояния и записи состояния могут быть сильно различными. Ну например, для автоматической поддержки аггрегируемых значений.
7. Существуют методы частичного вычисления. То есть, вместо того, чтобы выстраивать полный запрос, перенаправлять на таблицы которые уже содержат часть результатов.
8. В связи с предыдущим пунктом можно увеличить производительность, строя кэш результатов на те или иные объекты состояния(аналог материализованных вьюх, только в контексте OODB).
9. В связи с предыдущим пунктом можно даже увеличить производительность за счет поддержки индексирования значений методов.(точнее не даже, кое-кто такое поддерживает).

Таким образом с помощью объектов доступа программист может выстраивать слои, имея возможность инкапсулировать и прозрачно изменять всю логику OODB и при этом иметь высокоэффективный оптимизатор запросов.

Может я в чем-то ошибаюсь, все это IMHO, но это мое виденье хорошей OODB.

Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>ИМХО, любой апликейшен сервер это как-бы ООБД. Которая может использовать внешнюю РБД для хранения данных, индексации.

Но, в отличие от ООБД, сервер приложений не намертво привинчен к данным.

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

S>В своей ОБД я пришел к следующему.

S>- инкапсуляция не рекомендуется к применению.
S>- для особых случаев допускается бинарная сериализация ЧАСТИ объекта.

Это уже не OODB, а COODB, где C абревиатура от castrated. Это как раз то о чём говорит Иван, получается ни два, ни полтора. Кастрированная объектная модель и такая же неполноценная база данных.

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

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

IT>>По закону в штатах телефонные компании должны хранить данные о переговорах клиентов в течении нескольких лет, на случай, если ими заинтересуются соответствующие органы. Именно хранить, а не обрабатывать. При чём они могут их хранить хоть на бумаге.

Д>Хранить — не просто так. Хранить для того, чтобы потом их можно было прочитать. Может быть, это никому не понадобится. Но если бы не было этой задачи, то не было бы необходимости их хранить. Вообще.

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

IT>>ЗЫ. Тебе Merle уже в пятом топике говорит, что пора завязывать, но ты всё никак не угомонишься и продолжаешь демонстрировать свою... мягко говоря, неосведомлённость в обсуждаемых вопросах. Давай лучше завязывать, ok?

Д>Мягко говоря, ты тоже нарушаешь правила форума. Не к лицу это тебе, не находишь?

Вот видишь до чего порой доводят несознательные посетители

Д>Что касается моей осведомленности, то меня мало интересует чье-то мнение о ней. Я всего лишь хочу получить наконец ответы на вопросы.

Ты их получаешь, только почему-то не хочешь принимать. Создаётся впечатление, что у тебя есть свои ответы, с которыми наши не согласуются. Но вместо того чтобы выразить своё мнение и прояснить ситуацию, ты пытаешься запутать других. Про состояние объектов я тебе уже раз пять говорил, но ты либо беспросветно тупишь, в чём я лично очень сильно сомневаюсь, либо откровенно над нами издеваешься. В любом случае, водить хороводы вокруг этой темы лично мне уже надоело.

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

E>>Вероятно, скоро на вашем сайте появится статья: "Дмитрий Шуклин о перспективах полиморфизма без инкапсуляции".

S>Мало вероятно Тему следующей провокации я еще не выбрал

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

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

AVK>Ты когда нибудь видел в SQL-серверах возможность править результат select?
Вьюхи instead of.

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

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

S>> Какие здесь подводные камни?
M>Основной подводный камень — сделать все на основе ООБД. В самом понятии ООБД содержится некая ущербность. Дело в том, что ОО — это не голые данные, а прежде всего поведение. Иными словами ОО это некоторая обертка над данными, которая навязывает этим данным определенное поведение.

M>Из вышеказанного следует, что для систем с высокой степенью изменчивости и большим количеством разнородных данных, к которым относится и ОС, ООБД в чистом виде — не подходят.

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

Я тоже думаю, что ООБД не заменят РБД. Кстати, пора бы уточнить понятия. Тут уже начали говорить про активность объектов. Я то понимал под ООБД просто другую модель данных. Вместо плоской- иерархическую-сетевую с наследованием. Язык запросов какой-то отличный от SQL. А не то что объекты обязательно выполняются.

За РБД стоит теория. Интересно, что стоит за ООБД? Какие там языки запросов?

Кстати, для расширения кругозора: было предпринято много попыток прикрутить Пролог к РБД. Даже был такой европейский исследовательский проект по созданию реляционного ЯБД Дейталог, основанный на синтаксисе и идеях Пролога. У меня есть книжка. Так вот скажу, что в ней много разных теоретических математических подходов. Идея превосходная, но окончательной реализации вроде небыло предложено. Незнаю как сейчас, но что-то не слышно даже про Пролог. Боюсь что за терминами типа ООП, ООБД ничего не стоит кроме голой практики и более-менее сложные вещи сведут на нет все преимущества ООБД. Кстати, любопытно сравнить сложность реализации ООП в С++ и механизма вывода в Прологе. Последняя технология гораздо труднее для реализации и понимания. Я говорю только о сложности. Кажется ООП расширения Пролога тоже есть.

Кроме того моя любимая Бытовая Логика подсказывает, что само понятие БД предполагает наличие большого количества однородных данных слабо связанных друг с другом или находящихся в простых отношениях. Для этого идеальны таблицы. Такие вещи как наследование предполагают сложные взаимосвязи и древовидные-сетевые иерархии. В реальных задачах таких примеров наверняка меньше. Кстати, сетевые и иерархические базы данных появились если не раньше реляционных. И где они сейчас?

Вобщем, назовите задачи, которые требуют ООБД.

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

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

M>>Не смотря на то что ООП, как таковое, уже пережило бурный рост и движется к закату

Д>надо же, как интересно. А что, объектов больше не будет?

Ага. Их отменили.

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

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

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

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

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

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

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

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

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

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

Д>я не пытался сменить разговора.
Пытался, ты периодически передергиваешь и искажаешь чужие слова, вести конструктивный диалог в таких условиях невозможно, так что давай завязывать.

Д> Целью которых было как раз уточнить, что же ты имел в виду.
Если бы ты задавал вопросы именно с этой целью, то вся дискуссия бы прекратилась на втором сообщении.

Д>В ответ на что услышал, что я просто не понимаю твоих крутейших абстракций, всё время занимаюсь демагогией и враньем, и вообще извращаю высказанную тобой светлую истину.
Вот видишь, как раз очень хороший пример твоей демагогии, я нигде не утверждал, что высказанное мной светлая истина. Я лишь утверждал, что ты искажаешь мои слова, что ты сам, только что, блестяще подтвердил.

Д>Закат — это синоним слов "конец", "смерть". Отсутствие развития и "конец" — это совершенно разные вещи.
Так, давай поговорим о русском языке, отсутствие развития и "конец" — это конечно разные вещи, а вот отсутствие развития и "закат" вполне себе синонимы. Или ты это рассветом назовешь?
Кстати, еще одна иллюстрация передергивания.

Д>Далее. Почему обязательно развитие ООП должно остановиться?
Потому что его возможности уже исследованы, потенциал ясен, и класс задачь, для которых ОО подходит определен.

Д>почему?
Потому что принцип "расширять, гораздо выгоднее чем менять" — один из самых фундаментальных.

Д>не бывает такой задачи — "хранить данные".
Бывает.

Д> Бывает задача "хранить и обрабатывать данные".
Это две задачи. Есть задача хранить и есть задача обрабатывать. Причем задача обрабатывать, меняется гораздо чаще, чем хранить.

Д>Насколько часто ты видел полностью нормализованную базу без единой SP или триггера, кстати?
А при чем здесь SP и триггеры? Это всего лишь программа, которая может быть размещена где угодно.

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

GZ>Вопрос только насколько они действенны. Современная база данных это не только данные, но и поведение. Узнать о том, что данное поле заполняется автоматом с помощью триггера, можно только просмотрев реализацию триггеров. А информация о том что поле read only, или в каких случаях оно является read only, вполне полезно.
Да, действительо, все еще хуже, чем я описал. Часть метаинформации, описанная в императивном виде, вообще не поддается получению.
GZ>По поводу того, что нет информации о связях, согласен на все +1000. Но IMHO ты не совсем прав. Реляционка нуждается в ad-hoc запросах так как "ссылка на таблицу" недостаточное условие универсальности реляционки.
С точки зрения реляционки, все (почти) в порядке. Все будет полностью в порядке только при расширении трактовки понятия Foreign Key так, чтобы оно могло ссылаться не только на хранимую таблицу, но и на произвольное реляционное выражение.
GZ>Ну например такой запрос вполне жизненен.
GZ>

GZ>select *, ISNULL(organization.Name, citizen.Family) from document outer join organization on (document.signer = organization.id and document.sign_org=1)
GZ>outer join citizen on (document.signer = citizen.id and document.sign_org=0)
GZ>where document.signed is not null
GZ>

GZ>FK — как "ссылка на таблицу" — недостаточен. Нужно что-то более полиморфное.
Это мы уже забредаем на территорию ODBMS. Реляционка пренебрегает такими концепциями, как наследование и полиморфизм.

GZ>В принципе, в OODB это решается через наследование. Но тут легко получить, как ты выражаешься, выстрел в ногу. В случае оперативной памяти, мы легко получаем ссылку на экземпляр и его RTTI. В случае СУБД, экземпляр как таковой не инстанцирован, и получение экземпляра, или его ссылки — затруднено. IMHO Лучшим выходом в случае СУБД является явное указание конкретных типов который может адресовать ссылка. Указание же типа предка, подразумевает более широкий поиск возможного типа ссылки что не есть гуд.
Нет, тут никакой проблемы нету. Дерево наследования — всего лишь дерево; способ оптимизации для операции "получить всех потомков" хорошо известен — транзитивное замыкание.
Запрос, приведенный тобой выше, будет записан значительно короче, но при выполнении автоматически раскрыт в

select *, ResponsibleParty.Name from document outer join 
(
  select id, Name from organization
  union 
  select id, Family from citizen
)
where document.signed is not null

GZ>Данные могут быть полуструктурированы(короче говоря, меняющеяся от blob'a к blob'у схема).
Это само по себе уже не так сложно, как вообще поддержка хоть какой-то семантики о блобах. Вот, к примеру, модный Full-text Search от микрософта предлагает в таких случаяз заводить в таблице рядом с image полем колонку с расширением файла! Хоть бы MIME-тип использовали, позорники.
GZ>Зависит от обстоятельств. Иногда оптимизаторы пользуются индексами как отношением.
Неважно, как именно оптимизаторы пользуются индексами. С точки зрения реляционной алгебры индексов не существует. Точно так же, как арифметика прекрасно "работает" без оглядки на схемы ускоренного сложения, применяемые в электронике.
GZ>+1 Во первых, ты забыл вернуться к убогости SQL.
Не, не забыл. Просто слово это не написал.
GZ>Во вторых, ты темповую таблицу меришь по реализации в MSSQL. Там ублюдочная реализация. Темповая таблица — это некоторый промежуточный результат для получения других конечных результатов и которая не требуют транзакционности.
Пойми, что без ленивой семантики временная таблица — ублюдок вне зависимости от способа реализации. Ее где-то надо хранить, потому что к моменту ее использования информация о способе получения данных безнадежно потеряна. Если бы это была не таблица, а ссылка на реляционное выражение, то у оптимизатора оставался бы шанс как-то уменьшить стоимость запроса.

GZ>Меня волнует один вопрос. А как описывать/использовать статистику для рекурсивных запросов?
Точно так же, как и для обычных join. А что тебя беспокоит?

GZ>Я абсолютно согласен. Это было просто утверждение о реализации большинства OODB.
Ну, потому это большинство и делит %0.01 рынка обработки данных.
GZ>Проблема в том, что объект в оперативной памяти может быть достаточно большим. Его основная цель быть полноценным экземпляром.
Неа. В хорошей ODBMS должны реально инстанцироваться лишь немногие объекты.
GZ>Это процесс бесплатный если сравнить с падением производительности при чтении большого объекта в таблице. Поэтому, конечный тип может быть эфективнее если он сборный из двух и более таблиц. Вторая проблема — наследование. Join — отнюдь не самая легкая операция в СУБД, если хранить предка и потомка раздельно. В тоже время, если их хранить вместе, также невесело. На каждый тип свой запрос и свой проход по данным. При требовании, что объект поднятый с БД должен быть полноценным экземпляром подразумевает избыточность действий и данных.
Это все происходит от того заблуждения, что основной операцией является разрешение ссылки. Конечно, если не давать описывать более осмысленные операции, то во-первых придется руками указывать СУБД какой объект поднимать, а во-вторых ей придется поднимать полный объект, т.к. она не знает, что именно я собрался с ним делать.
Вот, например, РСУБД при удачном стечении обстоятельств может вообще обходиться без чтения таблицы ("инстанцирования кортежей"), если для выполнения запроса хватает данных в индексе. Точно так же должна работать ODBMS — достаточно дать ей доступ к коду. Тогда она сможет строить код, который работает в основном с данными на диске, но так, чтобы конечный результат был неотличим от полного перебора честных инстансов с соответствующими вызовами.
S>>Я не уверен, что эта нирвана связана с неудобством прямого управления состоянием.
GZ>Здесь выйгрыш в том, что код более гибкий. На СУБД — у нас одна обработка. На клиенте, который объект получил через web-сервис, другая обработка. В каждом слое приложения можно сделать свою обработку бизнес-объекта в соответсвии с целью, которая заложена в бизнес-логику слоя. При этом, они зависимы только по интерфейсу бизнес-объекта, а не по методам его получения или методам работы с хранилищем.
Согласен, это так.
GZ>Гы-гы. Собственно с помощью компонентной объектной модели можно скрыть факт о связи многие к многим, и о несовместимости логики за интерфейсом. Возможности не бесконечны но все таки более эффективны, чем при РСУБД.
Совершенно верно. Об этом я и говорю — чувство легкости при внесении изменений в РБД является ложным. Хорошо спроектированную ОБД будет не труднее, а легче поддерживать и развивать (а иначе нафига мы вообще это все придумываем???)

S>>На практике, имхо, 99% джойнов непосредственно связаны с foreign key. Поэтому можно сосредоточиться на оптимизации именно этих запросов, а все остальное трактовать как дополнительные критерии отбора, применяемые к результатам этих нативных операций. Фишка именно в том, что потребность джойнить именно любую таблицу с любой возникает крайне редко. "Адхокность" запросов, я уверен, можно сильно ограничить без особого ущерба для функциональности. Более того, возможно, что наличие подобных ограничений принесет больше пользы, чем вреда, принуждая разработчика к повышению качества проектирования приложений.
GZ>Если учесть полиморфизм ссылок(то о чем говорил вначале), то я согласен с тезисом что ad-hoc запросы избыточны и ненужны. IMHO Единственными пользователями ad-hoc запросов являются сами разработчики, и то, только те которые знают SQL.
Ну, на самом деле есть же тета-джойны, и от них никуда не уйдешь. "Выбрать те отделы, где средний возраст сотрудников выше, чем возраст начальника отдела". здесь использованы два FK и один предикат с неравенством. Впрочем, он в любом случае будет применен последним — после group by и join.
GZ>Тут возникает следующий вопрос. Сможем ли мы перевести большинство методов в селективные предикаты?
Ну, во-первых они не должны иметь побочных эффектов, иначе — сразу InvalidOperationException.
GZ>SQL с одной стороны много не позволяет.
Во-вторых, главное — выкусить "индексируемую" часть предиката, а остальное оставить в виде residual и честно вычислять.
GZ>Хотя в нем можно делать предикаты о которых не существует статистики, но это редкость. Будет ли это редкостью в коде OODB, еще вопрос.
Действительно, вопрос. Пока что мы говорим о гипотетической ООСУБД для гипотетической ООБД, и довольно сложно представить для чего это вообще будет применяться и как там ляжет карта со статистикой. Будет ли там 5000 классов в сложной иерархии? Будут ли там чудовищно сложные методы с рекурсивными вызовами, циклами и прочей ерундой? И т.д.

GZ>IMHO Тут может случиться казус с семантической оптимизацией. В данных условиях, подозреваю, что будет много повторяющихся предикатов, которые можно будет поубивать.
А что значит "поубивать"?
GZ>И скорее всего, нужно будет убивать промежуточные объекты, основной смысл которых предоставить путь от таблицы к таблице.
Ты имеешь в виду сбор мусора?

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

GZ>>Игорь, угадай на чем построена самая большая в мире база данных(подсказываю, это не РСУБД).
IT>Без понятия. К моему стыду я даже не знаю какую базу данных ты меешь ввиду
ReBar
У них кстати вышла по этому поводу интересная работа:
Lessons Learned from Managing a Petabyte

GZ>>Во первых, отчего же все меньше баз опубликовано в интернете, и все больше SOA? Реляционка как серьезная распределенная база данных — практически неприменима.
IT>И при чём тут ООБД? Или у неё здесь есть хоть малейший шанс вырваться вперёд?
Фактически да. OODB дает менее универсальное хранилище чем реляционка, но ее можно более эффективно подвернуть под конкретную задачу. Во первых, OODB — это уже готовый сервер приложений. Во вторых, сейчас наблюдается тенденция не хранения всего в единой универсальной базе данных с единым сервером приложений, а разделения функциональности по некоторой специализации. То есть вместо одного большого кластеризованного сервера приложений, некоторое кол-во поставщиков данных, и интеграционные сервера. А как поставщик данных, реляционка не слишком хороша, поскольку не умеет ни нормально их обрабатывать, ни гибко предоставлять. Для этого делают надстройки. Уже сейчас есть тенденции в отказе от традиционных реляционных решений в пользу более слабоструктурированных xml(можно даже проследить по форуму баз данных, куда я иногда захожу).
Ну и конечно то, о чем я говорил вначале. ООDB, в рамках манифеста, не теряет идентификацию данных. OID, в отличие от primary key, является всегда синтетическим ключом, и может адресовать данные находящиеся на другом хосте. Это полезное свойство при интеграции.

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

ГВ>>>А избыточность XML куда девать?
GZ>>А кто тебе сказал что данные в xml базе данных лежат в текстовом виде? Это не какой-нибудь парсер.

ГВ>Да это-то понятно. Но всё равно какая-никакая, но индивидуальная идентификация атрибутов должна быть.
Ну схему то никто не отменял.

ГВ>Я имею ввиду вот что.

ГВ>Например, если у нас есть таблица документов РБД, то данные можно уложить плотно, в соответствии со структурой таблицы. Мы в любом случае будем знать, что, скажем, по смещению 0x21 от физического начала записи начинается поле "дата документа". А вот в слабоструктурированом хранилище придётся к каждому фактическому атрибуту присовокуплять его идентификатор и сущность (или код идентификатора в каком-то словаре, не суть). По сумме это должно дать нехилый оверхед по габаритам или выродиться в РБД.
Нет. Оверхеда здесь особо нет даже для реляционок. Во вторых, можно конечно все держать в одной таблице, только это слишком неоптимально по структуре чтения. А количество чтений и записей, их порядок, пожалуй самые важные параметры говорящие о качестве базы данных. В третьих, кто сказал что так уж плохо, если это будет набор таблиц. Как не пыжся, внизу всегда будет реляционка, благо хранение в большинстве случаев последовательное. Все остальные типы баз — это вопрос надстроек над таблицами и математика их общения. Поэтому не надо присовокуплять(хорошее однако слово, надо будет запомнить).
И третье, у меня не хватает время следить за современными проектами по xml базам, а это было и пока еще популярно не хуже ООДБ и их очень многого я не знаю. Так что все ИМХО.

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

S>>Да. И считаю это основным достоинством ОБД.
M>А я считаю это причиной того, что ООБД обречены.
Зачем так категорично. Мое IMHO что эпоха ООБД еще не начиналась. Чтобы не повторяться, пост годичной давности:
здесь

Автор: GlebZ
Дата: 05.04.05

. Тогда тоже была весна(очевидно ООБД — это весеннее обострение).

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

M>>Не смотря на то что ООП, как таковое, уже пережило бурный рост и движется к закату

Д>надо же, как интересно. А что, объектов больше не будет?

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

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

S>>>Да. И считаю это основным достоинством ОБД.
GZ>Мое IMHO что эпоха ООБД еще не начиналась. Чтобы не повторяться, пост годичной давности:
GZ>здесь

Автор: GlebZ
Дата: 05.04.05

.

GZ>Нужна революция. Пролетарии всех стран, объединяйтесь!

GlebZ, присоединяйся к разработке Cerebrum, устроим революцию вместе

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

M>С моей точки зрения честная ООБД — это та, которая поддерживает, как минимум, наследоване, инкапсуляцию и полиморфизм, в том виде, в котором ее поддерживают современные объектные ЯП.

для начала давай уточним, какие из современных ЯП?

к тому же наследование — далеко не обязательный пункт
фактически, для соответствия ООП требуется всего два пункта — инкапсуляция и полиморфизм (полиморфизм != virtual method). Механизм расширения объектов (опять таки != наследованию) — желателен, но не обязателен.

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

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

S>>>>- инкапсуляция не рекомендуется к применению.

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

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

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

IT>Вот уж чья бы корово мукала насчёт неубедительной демагогии, а втоя бы лучше за собой последила. Пока кроме эмоций от тебя никаких убедительных аргументов не последовало. А аргументы и доказательства состоятельности своей позиции надо приводить как раз тебе, т.к. сегодня по истечении более десяти лет все попытки сделать OODB так и остались попытками.

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

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

S>ИМХО поддерживает в объеме достаточном для эксплуатации. А проблемы — где их нет. Про технические и идеологические проблемы своей БД я знаю. Много их там. Не было бы — не педалил бы следующую версию

Да вы уже давно себе решили — поддерживать индексы свойств нельзя, значит поля публичные и на них придется полагаться. И все — инкапсуляция долой и все с ней связанное. И опять работа со статичными данными вместо свойств. Могли бы подумать о динамическом реинжиниринге кода поисковых предикатов для работы с индексами прайват полей, но не стали... А теперь уж поздно все выбрасывать — новая версия как никак.

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

IT>>Эта эпоха может начаться только когда закончится эпоха написания кода человеком. Для человека это слишком сложная задача.
GZ>Скорее немного не так. Когда машина начнет понимать что человек написал. А DLinq уже может интерпретировать и трансформировать такой код. Так что эпоха не начинается, а можно сказать наступила.

Ну если DLing по твоему это шаг вперёд в нужном направлении, то нам ещё долго шагать

shuklin,

MS>>Ну и правильно. Делайте для себя и не тратьте время на чужое время — все равно все для себя. Другим оно вряд-ли пригодится.

S>Уже есть прециденты обратного.

Молодец! Вообще критика полезна, но как сам наверное понимаешь, угодить всем невозможно. Если у тебя что-то действительно новое, то продолжай делать дальше, невзирая ни на что и всё будет зашибись. Даже в самом крайнем случае тебя может постигнуть неудача, которая будет следующей ступенькой к успеху!

//Для поддержки энузиазма

Автор(ы): Steve Pavlina
Дата: 20.12.2004

В статье ''How To Get More Done in Less Time'' я писал о простом способе,
который может помочь постепенно увеличить продуктивность работы, не
требуя дополнительного времени. В этой статье я расскажу о нескольких
дополнительных способах сделать больше, не работая при этом
сверхурочно.

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

Д>А чем отличается "реальная распределенность" от "иллюзии распределенности"? Ты можешь привести какой-нибудь реальный пример?

Реальной распределённости при сегодняшнем уровне технологий добится очень сложно и то только за счёт гарантированных тормозов. Нужно транзакционно обновлять распределённое состояние объекта, т.е. делать что-то типа распределённого lock. Если эти требования снижать, то можно получить иллюзию распределённости. Например, мы можем принять такое допущение, что объект может изменяться только одним писателем, при этом доступ к объекту на время обновления его распределённого состояния разрешен, а возможными коллизиями мы можем пренебречь.

IT>>Ваня тебе уже всё рассказал про врождённые пороки ООП в ООБД, хочешь чтобы я его процитировал?

Д>всё, что он рассказал — это "ООП не работает". Как выяснилось, под "не работающим ООП" он понимает только одну из существующих реализаций ООП — вероятно, единственную, с которой он знаком. А возможность применения других реализаций или создания новых в его систему абстракций не укладывается никаким образом.

Ты можешь привести какой-нибудь реальный пример таких других реализаций?

Д>Какие принципиальные проблемы, которые можно избежать при отказе от ООП, ты видишь в данной задаче?

Синхронизация состояния.

GlebZ wrote:
> <http://www.slac.stanford.edu/BFROOT/www/Public/Computing/Databases/index.shtml&gt;
> У них кстати вышла по этому поводу интересная работа:
> Lessons Learned from Managing a Petabyte
> <http://www.slac.stanford.edu/BFROOT/www/Public/Computing/Databases/proceedings/CIDR05.pdf&gt;
Понравилось:

The technology that best fits bookkeeping is an
RDBMS. As with the eventstore, the specifics are
abstracted, allowing more than one RDBMS
implementation to be used. Some large centers, like
SLAC (which has an Oracle site-license) use Oracle,
while most small institutes opt for an open-source
alternative, MySQL.
...
The main goal is to provide a compact, simple catalog
for users to find the most common data quickly, while
allowing access to the full archive when needed.

Что вполне логично — основная объектная база используется для хранения
больших объемов сложносвязанных массивных данных. В основных данных не
надо делать поиск по многим таблицам со сложными объединениями, пути
доступа к данным относительно фиксированы и нужны сложные
числодробитильные вычисления на клиентах. В общем, идеальные условия для
ООБД.

Однако для каталога, наоборот, нужны ad-hoc запросы и быстрое их
выполнение. Отсюда и использование РСУБД.

> А как поставщик данных, реляционка не
> слишком хороша, поскольку не умеет ни нормально их обрабатывать, ни
> гибко предоставлять.
Проблема в том, что РСУБД пока лучше всего умеет поставлять
данные. И соответственно, лучше всего проявляет себя в задачах, где
нужно быстро и эффективно искать нужные данные.

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

> Для этого делают надстройки. Уже сейчас есть
> тенденции в отказе от традиционных реляционных решений в пользу более
> слабоструктурированных xml(можно даже проследить по форуму баз данных,
> куда я иногда захожу).
Скорее свидетельство buzzword'нутости...

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

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

Д>Не бывает задачи "просто хранить". Если данные где-то хранятся, то только для того, чтобы их обрабатывать. А просто БД с наглухо закрытыми входами и выходами — это из раздела розовых мечтаний DBA

По закону в штатах телефонные компании должны хранить данные о переговорах клиентов в течении нескольких лет, на случай, если ими заинтересуются соответствующие органы. Именно хранить, а не обрабатывать. При чём они могут их хранить хоть на бумаге.

ЗЫ. Тебе Merle уже в пятом топике говорит, что пора завязывать, но ты всё никак не угомонишься и продолжаешь демонстрировать свою... мягко говоря, неосведомлённость в обсуждаемых вопросах. Давай лучше завязывать, ok?

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

Д>если бы ты сразу сказал, что ключевая проблема, с твоей точки зрения — это состояние, то сэкономил бы массу времени и мне, и себе
Д>потому что я совсем не обязательно должен думать в том же направлении, что и ты (правда, удивительный факт?)

Удивительнее то, что мне пришлось это повторять так много раз.

Д>существуют реализации ООП, в которых нет состояния вообще. CLOS, например. Да и при программировании на других языках никто не запрещает применять аналогичный подход.

Вот ты опять пытаешься увильнуть куда-то в сторону? Ну при чём тут CLOS? ОО в CLOS и OOP, обсуждаемый в контексте топика объединяет только наличие и там и там двух букв OO. Видимо либо у тех либо у других не хватило фантазии придумать другой термин.

Д>Проблема наличия состояния и ООП — вещи абсолютно ортогональные.

В традиционном ООП — состояние вещь перманентная.

Д>но это тоже неважно, по большому счету. Потому что любая реальная система имеет состояние. Которое меняется. Которое нужно синхронизировать. И никуда ты от этого не денешься.

Ты же только что утверждал, что в CLOS не состояния вообще

Впрочем, с этим я спорить не буду. Состояние конечно же есть везде, только вопрос в том, какого время жизни этого состояния и является ли оно распределённым.

Д>также как и его наличие не создает эту проблему только фактом своего присутстия. Весь вопрос в дизайне системы, а ОО или не ОО — дело вообще десятое, не так ли?

Строя архитектуру на базе распределённого ООП ты не можешь этого избежать. И я пытаюсь тебе это сказать уже в десятый раз. Ты же мне в качестве контаргументов пытаешься доказать, что и без ООП можно накосячить. Можно, ещё раз тебе говорю. Да, можно, легко. Вот только в случае ООП у тебя не будет другого выхода.

Д>всего лишь пытался выяснить, что конкретно ты имел в виду тем примером. Сказать про состояние раньше ты почему-то забыл.

Я говорил о распределённости, которая не строится на ООП. О протокалах я вообще не говорил, это уровень коммуникации. Зачем ты его втащил в обсуждение вообще не понятно.

IT>>Ну хотя бы проблемы связанные с отсутствием строгой типизации.

Д>а кто сказал, что в смоллтоке, к примеру, нет строгой типизации? Скажи ты такое среди смоллтокеров — такой бы вой поднялся, что уши бы завяли
Д>ты просто путаешь слабую типизацию с динамической.

Таже фигня.

IT>>Вот опять ты за своё. Тебе ещё раз повторить, что бывают вещи необходимые, а бывают недостаточные?

Д>давай лучше я еще раз повторю, что среди пунктов "инкапсуляция, расширение, полиморфизм" нет пункта "обязательно иметь сосояние"?

Это всё нетрадиционные формы ориентации ООП. Учитвая, что сейчас нетрадиционные ориентации сильно в моде, то наверное в таком контексте ты прав

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

GZ>Проекция подразумевается как реляционная операция. Проекция — это трансформация типа. Что майнстримовые языки очень не любят.
Не, теперь у нас есть C#3, и там с этим почти все в порядке. Мне как раз нравится проекция, поскольку она позволяет четко разделить фазы выполнения запроса и использования результатов. Т.е. для того, чтобы получить ссылку на Product из OrderItem, я должен сразу же в запросе написать

from OrderItem o select o, o.Product

Попытка обратиться к o.Product в результатах — ошибка. (Причины — просты: есть риск, что к моменту dereference мы выйдем из контекста той транзакции, в которой выполнялся селект).
А еще лучше сразу написать

from OrderItem o select o.Amount, o.Product.FullName

потому что это позволит движку сделать всякие полезные оптимизации, избежать лишних букмарк лукапов и т.д. и т.п.
GZ>Уважаемый и ужастный Антон. Если вы хотя бы одним глазом заметили сии непотребные буквы на своем величайшем многопиксельном экране, прошу вас ответить. Что легче, парсить expression tree, или IL код? Заранее извиняюсь за беспокойство.
GZ>Вот, спросил.
Насколько я успел поверхностно разобраться — одна фигня. Потому что в лямбде я могу вставить вызов метода/свойства, и упс. Парни из Dlinq просто обошлись, AFAIK, набором готовых эвристик для трансляции известного кода. Типа "a".Length превращается в Len('a') и еще некоторый более-менее убогий набор функционала.
По-хорошему, надо делать так же, как сиквел разбирает UDF: лезть унутрь этого метода, смотреть в его MSIL и т.п. В частности, убеждаться в том, что метод не меняет состояние объекта (это сразу InvalidOperationException), проверять, не получилось ли случайно так, что можно воспользоваться индексом, и т.п. Иначе банальный селект, где сравнивается свойство с константой, будет сливать, т.к. индекс построен по полю. Так что от IL можно уйти только очень недалеко и ненадолго.

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

Д>заблуждение — это валить задачи OLAP и OLTP в одну кучу. Никому не нужно решать "задачу хранения фактов вообще" одним на всех универсальным образом, всех интересует только решение их частных задач.

Ага, только частные задачи оказываются очень широкими. Те же OLTP используются как сырье для OLAP, причем разных видов. Записи о первичках и текущие ведомости формируют, и различные виды учетов, и аналитику по ним строят. Причем, зачастую, все это разные приложения.

Д>Совсем другое дело — OLTP, где данные меняются очень часто, а читаются сравнительно редко.

Меняются? Скорее добавляются.

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

EXO>Задача клиента, в техуровевой архитектуре — отображать.
EXO>Удобно, качественно, в разных вариантах — но только отображать.

Не так. Задача клиента — обеспечивать взаимодействие с пользователем. А там есть еще обратное направление — преобразование действий пользователя в команды получения и изменения данных. И здесь все становится много-много печальнее.

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

GZ>гемоэнцэфалический барьер

Не сочтите за наезд, но <b>гематоэнцефалический</b> барьер

Здравствуйте, Adopt, Вы писали:
A>только не пинайте
A>Что такое таблица с B+ индексом?
Какое именно из слов тебе непонятно?

Здравствуйте, GlebZ, Вы писал
GZ>Легко сказать да трудно сделать. Страдаю глобализмом.

GZ>Итак. Прежде всего некоторые тезисы. Тезисы по поводу РСУБД, касаются именно именно идеальной реляционки времен Кодда и SystemR. Кое что было решенов рамках СУБД, кое что с помощью сервисов поставляемые с той, или иной базой данных.
GZ>1. Недостаток РСУБД. Скудность информации данных. Зачастую о смысле данных можно узнать только перерыв приложение которое его использует.
Хм. Не очень ясно, что же ты имеешь в виду. Я попробую развернуть здесь эту критику поподробнее:
— отсутствие внятной концепции метаданных. Классический SQL вообще не содержал средств работы с метаданными. Клиентское приложение должно было получить знания о таблицах/view и их колонках эзотерическим путем). Справедливости ради стоит отметить, что в новых версиях стандарта SQL работа с метаданными таки предусмотрена
— малое внимание к связям. FK трактуются как декларативные ограничения, к которым довольно сложно получить доступ, в то время как это на самом деле first-class citizens. Фактически, объявление FK вводит новый тип данных — "ссылка на таблицу", и это должно быть очевидно и легкодоступно.
— 100% отсутствие информации о структуре бинарных объектов. Тут уже точно пошла жесткая необходимость рыться в исходниках клиентского приложения для понимания сути blob.
Работы по поддержке пользовательских типов вместо blob и переносе хотя бы части семантики внутрь БД не слишком скоординированы. Насколько я знаю, попытки стандартизовать UDT есть, но реальная картина в мире СУБД печальна: каждый производитель тянет одеяло на себя. Кстати, стоит отметить полную бесперспективность данного подхода в отстутствие управляемой среды: исполнение пользовательского кода в контексте сервера, который должен обеспечивать высокую надежность — самоубийство.

GZ>2. Недостаток РСУБД. Недостаточная эффективность реляционной модели. Вряд ли что эффективней работает на строгоструктурированными данными чем РСУБД, но так как мы имеем данные огромного объема даже этого механизма не хватает. В ответ на это появились вычислимые поля на триггерах, материализованные вьюхи, временные таблицы и прочая лабуда.
Я бы не был так категоричен. Сама по себе реляционная модель не может обладать никакой эффективностью. Есть средства эффективной реализации некоторых выражений реляционной алгебры. Например, это индексы. Важно понимать, что индексы не являются частью реляционной модели. Опять же важно понимать, что каждый тип индексов приспособлен для оптимизации определенного класса запросов. Популярность B+tree напрямую связана с широтой класса улучшаемых запросов. Тем не менее, B+tree — не панацея. Есть и другие типы индексов, которые могут оказаться уместными в различных ситуациях. В частности, агрегатные индексы, типичные для OLAP-баз, позволяют добиться невероятных результатов. При работе с древовидными данными разработчики как правило реализуют ту или иную схему индексации поверх основной реляционной модели (Селковские диапазоны или транзитивное замыкание).
Материализованное view — это паллиатив, попытка реализовать сразу несколько типов индексов, не встроенных в движок. Временные таблицы — это вообще нонсенс; это попытка обойти либо ограничения выразительности языка, либо ограничения оптимизатора. И если со вторым еще как-то можно смириться — оптимизаторы неуклонно совершенствуются, и нужда явно указывать способ хранения промежуточных результатов снижается, то проблема с первым напрямую связана с убогостью SQL. К этому пункту мы еще вернемся.
GZ>3. Недостаток РСУБД. Даже для задачи хранения и получения данных, нужны вычисления. А для вычислений нужен язык. В РСУБД были внедрены языки, но поскольку первичная их задача — доступ к данным. На вычислительную мощность, и, в большей степени, на удобство пользования разработчики положили.
GZ>4. Недостаток РСУБД. Недостаточность инкапсуляции. Вьюхи в классическом виде не выполняют своей роли полностью так как работают на чтение. На данный момент можно пользовать stored procedure, которую нельзя включить в custom SQL запрос. Или с помощью триггеров instead of навешанную на VIEW или Table. Еще в некоторых базах существуют функции(сразу признаюсь что не знаю, используются они в оптимизации запросов, или нет).
В общем-то да. Жизнь показала, что потребность в запросах в основном сводится к вытаскиванию данных. Опять же, нужно понимать, что стоимость движка напрямую зависит от заявленной функциональности. Я думаю, что нормальная спецификация SQL могла быть разработана еще в начале 80х, но она бы так и лежала на полке из-за проблем с реализацией.
Тем не менее, надо понимать, что фундаментальными проблемами SQL являются:
— отсутствие внятной модели скалярных функций, в том числе и с рекурсивным определением
— отсутствие внятной модели реляционных функций
Стоит отметить, что современные коммерческие RDBMS хоть как-то пытаются решать эти вопросы. Тем не менее, я до сих пор не знаю СУБД, где можно передать внутрь функции ссылку на реляционное выражение. Все, что пока возможно — это построить функцию со скалярными аргументами, которая вернет таблицу. Причем далеко не все производители реализуют такую функциональность с приемлемой эффективностью. Abstraction penalty в некоторых случаях больше похожа на death sentence: например, в Interbase никакой оптимизации табличных функций в принципе не было (на момент версии 5.6, с которой я съел достаточное количество соли, возможно это исправили в новых клонах). В MS SQL разработчику хотя бы дают выстрелить себе в ногу.
Вместо расширения декларативной модели, комитет изобретает частные затычки — например, CTE. О, классно, мы теперь можем делать рекурсивные запросы, ура! Если бы SQL позволял писать table-valued функции с табличными параметрами, мы получили бы то же самое в качестве побочного эффекта. Увы и ах.


GZ>5. Недостаток OOСУБД. Инкапсуляция. Инкапсуляция хороша от внешних злодеев, и очень вредна внутри OOСУБД. Наибольший пострадавший в данном случае — оптимизатор запросов.
Это неверно. Инкапсуляция вовсе не означает криптологию: она фактически запрещает строить код, статически завязанный на подробности реализации, а вовсе не получать информацию о внутреннем устройстве кода. Ну, вот например, допустим компилятор С++ видит в некотором месте вызов метода A::a(). Соответствие областей видимости компилятор проверит первым делом, так что внешний код скомпилируется только если a() public, и т.п. Но сразу после выполнения этой проверки компилятор может забыть все эти модификаторы доступа. Если внутри этого метода всего лишь идет обращение к полю экземпляра, пусть даже и приватному, компилятор имеет полное право устранить вызов путем инлайнинга и выполнять прочие модификации. С точки зрения С++, private прячет интимности от кода, но не от компилятора. С точки зрения управляемой среды, оптимизатор всего лишь имеет права "врача, священника, и мужа" по отношению к коду хранимых сущностей, т.е. соответствующий reflection permission. Это никак не нарушает инкапсуляцию.

GZ>6. Недостаток OOСУБД. Слишком сильная привязанность к таблицам и месту хранения. Во многом это усуглубляет недостаток РСУБД из пункта 2 полученный в наследство. Даже скажу, очень сильно усуглубляет.
Вот это я не очень понимаю. Это же неудачное стечение двух совершенно различных обстоятельств: отстутствие достаточно декларативного языка запросов, и отсутствие оптимизатора, который мог бы воспользоваться избыточной информацией в индексах.

GZ>7. Недостаток OOСУБД. Объект который имеет состояние, и управляет им тяжел и неудобен в сопровождении. После того, как я перестал использовать в бизнес-объектах функционал реализующий работу с их состоянием, чессно-слово, обрел нирвану. Поэтому желательно разделение бизнес-объекта и бизнес-сервиса. Таким образом это улучшает сопровождаемость кода.
Я не уверен, что эта нирвана связана с неудобством прямого управления состоянием. Вообще, конечно же, статическая трактовка данных, принятая в RDBMS, сильно упрощает жизнь. Хотя это вовсе не 100% упрощения, и проблемы с сопровождением все равно есть. В самом оптимистичном случае, когда вносимые изменения не требуют модификации фактологической модели (т.е. мы, к примеру, все еще считаем "телефон" скалярным атрибутом сущности "клиент", а не заменяем это на связь многие-ко-многим), все равно есть риск нарваться на несовместимость логики, когда данные находятся в состоянии, валидном с точки зрения предыдущей модели, но недостижимом в новой модели. Основное упрощение в RDBMS связано с тенденцией консолидировать логику в относительно небольшое количество крупных фрагментов. Однако у этой палки есть и обратная сторона: низкий уровень декомпозиции увеличивает общий объем необходимых изменений. В хорошо спроектированной объектной модели логика состоит из большого количества слабо связанных фрагментов, и все изменения можно четко локализовать.

GZ>8. Принцип Деметры(принцип хорошего проектирования):
GZ>

GZ>Для любого класса C и для любого метода M, связанного с C, все объекты, которым M посылает сообщение, должны быть экземплярами классов, ассоциированными со следующими классами: классами аргументов M (включая C); классами переменных экземпляра C.

GZ>Взято отсюда.здесь. Интересная статья, советую прочитать.
GZ>9. Предыдущий пункт сильно противоречит ad-hoc запросам в РСУБД в которых ты можешь взять любую таблицу, и сджоинить с любой другой таблицей. Правда при этом надо учитывать фактор индексов, без которых данная операция будет безбожно тормозить.
На практике, имхо, 99% джойнов непосредственно связаны с foreign key. Поэтому можно сосредоточиться на оптимизации именно этих запросов, а все остальное трактовать как дополнительные критерии отбора, применяемые к результатам этих нативных операций. Фишка именно в том, что потребность джойнить именно любую таблицу с любой возникает крайне редко. "Адхокность" запросов, я уверен, можно сильно ограничить без особого ущерба для функциональности. Более того, возможно, что наличие подобных ограничений принесет больше пользы, чем вреда, принуждая разработчика к повышению качества проектирования приложений.

GZ>9. Все что можно уже выдумано до нас. В частности компонентность и модификаторы компонентности.
?
GZ>10. Все что можно уже выдумано до нас. В частности версионификация. Объекты легко адаптируют в компонентной программе сразу для нескольких клиентов.
?
GZ>12. Недостаток OODB. Он пытается увеличить скорость навигационных запросов путем адаптации хранилища к ним. Он сознательно адаптирует хранилище под конкретное приложение согласно объектной схеме. (Это я намекаю на хранение подчиненных коллекций и объектов вместе с объектом владельцем). Соответвенно теряется эффективность ad-hoc запросов.
Угу. Я считаю это членоудлинительством: много рекламы и мало практической ценности. Такие ODBMS оптимизируют самую ненужную операцию: инстанцирование комплексных объектов. Вместо этого необходимо уменьшать количество объектов, которые надо инстанцировать в рамках выполнения запроса.
GZ>12. Для оптимизатора запросов важна подробная информация.
Ну, с этим никто не спорит. Вообще здесь, как и много где еще, работает правило Парето: 80% успеха обеспечивается 20% усилий.
В частности, для RDBMS оказывается, что даже минимальной статистики (типа количества уникальных значений ключа индекса) достаточно для выбора планов, близких к оптимальным. Следующий шаг — построение гистограмм распределений — позволяет добиться еще некоторого сокращения лишних операций. Дополнительная семантическая оптимизация на основе данных о констреинтах позволяет улучшить планы в граничных случаях. В принципе, уже этой информации достаточно оптимизатору для того, чтобы почти не оставить шансов человеку на улучшение запросов.
Вменяемый ODBMS оптимизатор должен справляться не хуже. Все, что ему нужно — доступ к телу используемых методов. Все равно в итоге идет обращение к полям экземпляров и классов; поэтому особенной разницы в оптимизациях нет. С одной стороны, все кажется сложным — типичный "объектный" запрос будет иметь значительно более сложное AST, чем типичный реляционный. С другой стороны, есть очень хороший шанс использовать кэш. В частности, если посмотреть на статистику Jit для Януса, то окажется, что в этом приложении обработано всего ~2600 методов. Новые методы будут появляться крайне редко (относительно количества вызовов этих методов), а, значит, можно не выполнять дорогостоящий анализ каждый раз.

GZ>Итак вооружившись этими тезисами, начинаю сочинять(играю как умею, в пианиста не стрелять).
Я пока поскипаю обсуждение конкретных предложений, т.к. не готов играть на равных

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

Всё-таки оставил последнее слово за собой, хитрец

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

M>Сейчас с успехом пользуются данными кропотливо вносимыми с семидесятых годов, за это время они перекочевали через нескольких поколений хранилищ и пережили сотни способов интерпретации, и вряд ли это было бы возможным если бы в самом начале использовались объектные хранилища или даже иерархические.
Иван, что-то здесь не понял. А какие были БД в 70-ых?

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

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

S>> Какие здесь подводные камни?
M>Основной подводный камень — сделать все на основе ООБД. В самом понятии ООБД содержится некая ущербность. Дело в том, что ОО — это не голые данные, а прежде всего поведение. Иными словами ОО это некоторая обертка над данными, которая навязывает этим данным определенное поведение.
M>Таким образом, предлагая хранить объекты, ты предлагаешь хранить определенное поведение,

Да. И считаю это основным достоинством ОБД.

M>что как минимум довольно здорово ограничивает возможности самих данных. Все бы ничего, если бы речь шла о какой-то конкретной довольно узкой задаче, ...

Если так, то stored procedures в БД места быть не должно

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

S>Да. И считаю это основным достоинством ОБД.
А я считаю это причиной того, что ООБД обречены.

S>Если так, то stored procedures в БД места быть не должно
Не передергивай. sp — это лишь программа, которая может лежать где угодно, на сами данные она ни как не влияет.

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

GZ>Иван, что-то здесь не понял. А какие были БД в 70-ых?
Кто говорил про БД? Я говорил про данные...

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

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

S>>Да. И считаю это основным достоинством ОБД.
M>А я считаю это причиной того, что ООБД обречены.

А я считаю это причиной того, что РБД обречены на провал, а ОБД обречены на успех.
Время нас рассудит.

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

S>Время нас рассудит.
Время уже расудило.
Не смотря на то что ООП, как таковое, уже пережило бурный рост и движется к закату — ни одной полноценной ООБД успешно проявившей себя на хоть сколь-нибудь заметном количестве промышленных задачь так и не появилось, не смотря на многочисленные попытки. А все потому, что данные != объект, и загонять данные в рамки объекта, ограничивая тем самым возможности по их интерпретации, можно только в случаях очень высокой предсказуемости системы, но, к сожалению, величиная таких задачь исчезающе мала.

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

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

S>>Время нас рассудит.
M>Время уже расудило.
M>Не смотря на то что ООП, как таковое, уже пережило бурный рост и движется к закату — ни одной полноценной ООБД успешно проявившей себя на хоть сколь-нибудь заметном количестве промышленных задачь так и не появилось, не смотря на многочисленные попытки. А все потому, что данные != объект, и загонять данные в рамки объекта, ограничивая тем самым возможности по их интерпретации, можно только в случаях очень высокой предсказуемости системы, но, к сожалению, величиная таких задачь исчезающе мала.

Это очень ограниченная точка зрения. В плане структурной интерпретации данных ОБД гораздо багаче РБД и включают РБД в себя как частный случай. Однако создание ООСУБД технически гораздо более сложная задача, по сравнению с созданием РСУБД. Развитие пошло просто по более простому пути. А последние выбрыки производителей РСУБД по включению туда поддержки деревьев, XML и прочего как раз говорят о начинающемся закате РСУБД.

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

S>Это очень ограниченная точка зрения.


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

S> и включают РБД в себя как частный случай.
А вот это, пожалуй, довольно однобокая точка зрения..

S> Однако создание ООСУБД технически гораздо более сложная задача, по сравнению с созданием РСУБД.
Технически ничего сверхсложного нет. Современным движкам РСУБД, по большему счету, совершенно все равно что хранить внутри, реляционные таблицы или совершенно абстрактные объекты.

S> Развитие пошло просто по более простому пути.


S>А последние выбрыки производителей РСУБД по включению туда поддержки деревьев, XML и прочего как раз говорят о начинающемся закате РСУБД.
У меня есть любмая байка по этому поводу. Знаешь как MSSQL хранит XML для оптимальной вставки, поиска и вообще работы XQuery?
По некоторым данным ребята потратили около восьми лет на исследования как это лучше сделать, а в итоге пришли все к той же банальной реляционной таблице с B+ индексом, вот и весь XML.
Так что идет не уход от реляционки, а наоборот, скорее развитие реляционки, в сторону навешивания на нее как можно большего встроенного функционала.

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

M>Не смотря на то что ООП, как таковое, уже пережило бурный рост и движется к закату — ни одной полноценной ООБД успешно проявившей себя на хоть сколь-нибудь заметном количестве промышленных задачь так и не появилось, не смотря на многочисленные попытки. А все потому, что данные != объект, и загонять данные в рамки объекта, ограничивая тем самым возможности по их интерпретации, можно только в случаях очень высокой предсказуемости системы, но, к сожалению, величиная таких задачь исчезающе мала.

ИМХО, любой апликейшен сервер это как-бы ООБД. Которая может использовать внешнюю РБД для хранения данных, индексации. Не зря Gemstone/S предпочитают называть не ООБД, а именно сервером приложения.

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

M>Не смотря на то что ООП, как таковое, уже пережило бурный рост и движется к закату

надо же, как интересно. А что, объектов больше не будет?

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

M>>Не смотря на то что ООП, как таковое, уже пережило бурный рост и движется к закату

Д>надо же, как интересно. А что, объектов больше не будет?

ИМХО он имел ввиду ООБД.

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


S>> В плане структурной интерпретации данных ОБД гораздо багаче РБД
M>Как ты будешь интерпретировать инкапсулированные данные, расскажи пожалуйста.
M>Или, например, строить несколько равнозначных видов иерархий для разных представлений одних и тех же данных, при том, что эти данные, сами по себе, лежат отнюдь не в плоском виде (у тебя же объекты)...

Ок. Давайте подискутируем на эту тему. Меня она очень интересует как разработчика собственной ООСУБД/БЗ


M>Как ты будешь интерпретировать инкапсулированные данные, расскажи пожалуйста.
— инкапсуляция в ОБД ИМХО не столь категорически важна, как в ООП. Действительно строить индексы по вычисляемым полям объектов занятие не для слабонервных. Но ведь и РБД это не умеют. Это просто очень нетривиальная задача, не зависимо от того сеть или таблица является физическим уровнем для хранения полей объектов.

В своей ОБД я пришел к следующему.

— инкапсуляция не рекомендуется к применению. Поля объекта открыты для доступа независимо от методов самого объекта. К этим полям система может обращаться не инстанциируя сам объект.

— для особых случаев допускается бинарная сериализация ЧАСТИ объекта. В этом случае программист отгребает все от ручной сериализации и прочих недостатков, о которых ты намекаешь. Согласен. Зато бинарная сериализация действительно быстрее.
Я предпочитаю иметь и предоставлять выбор, работать в стиле РБД — без явной инкапсуляции, либо в стиле ООП.

Теперь расмотрим VIEW как аналог инкапсуляции в РБД. Я поддерживаю объектные VIEW. Поддержка реализована на двух уровнях.
— на уровне модели данных один и тот же аттрибут может быть чайлдом нескольких экземпляров объектов. Это позволяет формировать объекты являющиеся JOIN аттрибутов других объектов, без потери идентичности и возможности адресации аттрибутов по указателям.

— на уровне собственно экземпляров — благодаря поддержке самим .NET множественного наследования интерфейсов и известным ООП паттернам, типа мост, адаптер, обертка, ...

M>Или, например, строить несколько равнозначных видов иерархий для разных представлений одних и тех же данных, при том, что эти данные, сами по себе, лежат отнюдь не в плоском виде (у тебя же объекты)...

В последней версии тоже просто — благодаря сетевой архитектуре поддерживаемой на нескольких "уровнях". Экземпляр объекта представляет собой некоторого вида "иерархию" аттрибутов. Однако аттрибут может иметь несколько парент объектов. (паттерн FLYWEIGHT) Таким образом можно строить на основе одних и тех же экземпляров (скаляров, композитов) различные иерархии. — это "глубинный уровень". Тоесть "иерархия" является на самом деле сетью.

Во всех версиях на "семантическом уровне" благодаря возможности окраски связей графа с помощью ИД можно проводить операции близкие к JOIN в РБД. Тоесть что то типа WHERE ИД_СВЯЗИ(связь) = ИД_ОБЪЕКТА(объект) А это в Cerebrum было всегда. Даже в VNPI-99


S>> и включают РБД в себя как частный случай.
M>А вот это, пожалуй, довольно однобокая точка зрения..

Как раз нет. Самый примитивный вариант ОБД — это РБД с еще одним дополнительным скрытым полем в строке — vtbl и возможностью вызова через этот vtbl методов ассоциированных со строкой.


S>> Однако создание ООСУБД технически гораздо более сложная задача, по сравнению с созданием РСУБД.
M>Технически ничего сверхсложного нет. Современным движкам РСУБД, по большему счету, совершенно все равно что хранить внутри, реляционные таблицы или совершенно абстрактные объекты.

Более сложная не значит не выполнимая, если создание ядра ОСУБД — один челвеко год, во время свободное от семьи, пива, работы, ...

M>Так что идет не уход от реляционки, а наоборот, скорее развитие реляционки, в сторону навешивания на нее как можно большего встроенного функционала.

Тем хуже для Microsoft & Oracle. Почемуто я им не сочуствую ))))

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

ANS>>ИМХО, любой апликейшен сервер это как-бы ООБД. Которая может использовать внешнюю РБД для хранения данных, индексации.

AVK>Но, в отличие от ООБД, сервер приложений не намертво привинчен к данным.

Видимо не нужно /было/ иерархические БД называть ООБД. Тогда термин ООБД, можно будет /можно было бы/ использовать более "по назначению".

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

S>- инкапсуляция в ОБД ИМХО не столь категорически важна, как в ООП.
Понятно. Вот и не объектная у нас бд...

S> Но ведь и РБД это не умеют.
Это не отмазка. Реляционка так и задумывалась как голые данные, а в объектах должна быть инкапсуляция иначе это уже не объекты.

S> Это просто очень нетривиальная задача
Она, прямо скажем, не разрешима на современном уровне развития техники.

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

S>В последней версии тоже просто — благодаря сетевой архитектуре поддерживаемой на нескольких "уровнях". Экземпляр объекта представляет собой некоторого вида "иерархию" аттрибутов. Однако аттрибут может иметь несколько парент объектов. (паттерн FLYWEIGHT) Таким образом можно строить на основе одних и тех же экземпляров (скаляров, композитов) различные иерархии. — это "глубинный уровень". Тоесть "иерархия" является на самом деле сетью.
Вот и получаем, вместо прохода по плоскому списку ползание по иерархиям... Задумайся, почему при работе с обычной реляционкой, в большинстве случаев, для построения отчетов все ORM посылаются в лес и гоняются прямые и незатейливые запросы к плоским данным...

S>Как раз нет. Самый примитивный вариант ОБД — это РБД с еще одним дополнительным скрытым полем в строке — vtbl и возможностью вызова через этот vtbl методов ассоциированных со строкой.
И кто кого после этого частный случай..

S>Более сложная не значит не выполнимая, если создание ядра ОСУБД — один челвеко год, во время свободное от семьи, пива, работы, ...
Не, ну ты определись. Либо вся индустрия еще не докумекала и поэтому ООБД нету, либо один человек за год слабал...

S>Тем хуже для Microsoft & Oracle.
Ню-ню...

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

Д>надо же, как интересно. А что, объектов больше не будет?
Почему? Кудаже без них, только вот не везде и не всегда с ними удобно.

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

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

S>>- инкапсуляция в ОБД ИМХО не столь категорически важна, как в ООП.
M>Понятно. Вот и не объектная у нас бд...

Можете считать ее какой угодно

S>> Но ведь и РБД это не умеют.
M>Это не отмазка. Реляционка так и задумывалась как голые данные, а в объектах должна быть инкапсуляция иначе это уже не объекты.

Моя тоже так задумывается, дальше что?

S>> Это просто очень нетривиальная задача
M>Она, прямо скажем, не разрешима на современном уровне развития техники.

Посмотрим

S>>Я предпочитаю иметь и предоставлять выбор, работать в стиле РБД — без явной инкапсуляции, либо в стиле ООП.
M>При этом рекомендованый в стиле реляционки. Классная ООБД получается..

Именно как задумывается так и получаецца

M>Вот и получаем, вместо прохода по плоскому списку ползание по иерархиям... Задумайся, почему при работе с обычной реляционкой, в большинстве случаев, для построения отчетов все ORM посылаются в лес и гоняются прямые и незатейливые запросы к плоским данным...

Если ОРМ посылаются в лес, странно что туда же РБД за компанию не посылают При ползании по JOINs и лишним индексам — туда им и дорога.
Только не надо говорить, что в промышленных сценариев JOINами и не пахнет

M> либо один человек за год слабал...
А ты загрузи и зацени
Потом сюда недостатки, я их обдумаю, и возможно приму к разработке. По любому будет от меня тебе пасибо.

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

M>Почему? Кудаже без них, только вот не везде и не всегда с ними удобно.

а где с ними неудобно, интересно?

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

AVK>Но, в отличие от ООБД, сервер приложений не намертво привинчен к данным.
Что значит привинчен?

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

S>Можете считать ее какой угодно
S>Моя тоже так задумывается, дальше что?
Дальше — не надо называть ее "О". И вообще про объекты речь не вести.

S>Если ОРМ посылаются в лес, странно что туда же РБД за компанию не посылают
Ну я же предложил тебе задуматься. Подумай, почему ORM посылают, и обращаются напрямую к реляционке.

S>При ползании по JOINs и лишним индексам — туда им и дорога.
Индексы здесь непричем.

S>А ты загрузи и зацени
Пока такого желания нет, идеология неверная.

S>Потом сюда недостатки.
На недостатки я уже указал — иерархические БД и в частности объектные, подходят для довольно узкого класса задачь, причину я указывал...

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

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

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

GZ>Зачем так категорично.
Лучше сразу с этим смириться...

GZ> Мое IMHO что эпоха ООБД еще не начиналась.
Да пора бы уже заканчиваться, она лет 15 все начинается...

GZ> это весеннее обострение.
Да уж, только пригибайся..

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

GZ>> Мое IMHO что эпоха ООБД еще не начиналась.
M>Да пора бы уже заканчиваться, она лет 15 все начинается...
Вон Влад и adontz возятся с новой игрушкой. Как дети. Значит что-то кардинальная изюминка в ней есть. А общая идея ведь датируется шестидесятыми.

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

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

если есть данные и есть методы для работы с ними — это уже ООП.... Не вижу ни в одном из этих случаев ни малейших проблем.
а где именно рассказывал?

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

GZ>Вон Влад и adontz возятся с новой игрушкой. Как дети. Значит что-то кардинальная изюминка в ней есть. А общая идея ведь датируется шестидесятыми.

ничто не ново под луной... секс вообще в незапамятные времена изобрели, и до сих пор не надоедает

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

IT>Будут радёмые, куда же без них. Но вот совать ООП куда ни попадя, как то в базы данные или в распределённые среды, где ООП плохо работает, и искать в ООП панацею народ потихонечку прекращает.

Я все-таки так и не понял, что именно в ООП плохо работает и при каких условиях?

IT>Самодостаточная персистентная распределённая объектная модель мира — это утопия.

А знаешь, где здесь заключается утопия? В словах "модель мира". Всё остально — вторично. Можешь подставить "функциональная", "структурная", "реляционная" или просто "математическая" — утопизма от этого не убавится.

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

S>>Можете считать ее какой угодно
S>>Моя тоже так задумывается, дальше что?
M>Дальше — не надо называть ее "О". И вообще про объекты речь не вести.

А может не надо ODMG называть объектной группой ? Это вопрос точки зрения. Моя личная практика говорит мне что это у них и у Вас с идеологией проблемы

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

Д>>а где с ними неудобно, интересно?
M>Например, везде, где необходимо работать с голыми данными, БД, распределенка, репорты, ect... О причинах я уже рассказывал...

Ваши доводы или совершенно неубедительны, или доказывают прямопротивоположную точку зрения.

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


S>>- инкапсуляция не рекомендуется к применению.
S>>- для особых случаев допускается бинарная сериализация ЧАСТИ объекта.

IT>Это уже не OODB, а COODB, где C абревиатура от castrated. Это как раз то о чём говорит Иван, получается ни два, ни полтора. Кастрированная объектная модель и такая же неполноценная база данных.

И что же такого важного я не смогу провернуть в такой модели, что можно провернуть в вашей? Как раз наоборот. Это вы в своей "полной" модели не сможете сделать многого что я смогу сделать в своей "castrated" Поэтому считаю ваши доводы неубедительной демагогией.

IT>Кстати, современные ОРМ и всевозможные мапперы совсем неплохо справляются с преобразованием данных БД в объектную модель и наоборот. На это у разработчиков уходит всё меньше и меньше времени. Для большинства операций это реализуется зачастую лишь одной строчкой кода. При этом мы имеет и полноценную БД и ничем искуственно не ограниченную объектную модель.

И на маппинг там время не тратится, и сети поддерживаются по полной, Ну ну.

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


Д>если есть данные и есть методы для работы с ними — это уже ООП.... Не вижу ни в одном из этих случаев ни малейших проблем.
Д>а где именно рассказывал?

Аналогично. В отличие от педантов, для которых секурити (инкапсуляция) важнее функциональности, я считаю основным достоинством ООП полиморфизм. А вот его то я поддерживаю в своей БД максимально.

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

Д>если есть данные и есть методы для работы с ними — это уже ООП....
Смело... Ну пусть.
Далее, в зависимости от задачи, для одних и тех же данных нужны разные методы, соответственно, следуя твоей логике, разное ООП.
Как перейти из одного ООП к другому ООП минуя прямую работу с данными?

Д> Не вижу ни в одном из этих случаев ни малейших проблем.
Везет же...

Д>а где именно рассказывал?
Re: Файловые системы, файлы, приложения &mdash; устаревшие концепц

Автор: Merle
Дата: 20.04.06

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

Д>>если есть данные и есть методы для работы с ними — это уже ООП....
M>Смело... Ну пусть.
M>Далее, в зависимости от задачи, для одних и тех же данных нужны разные методы, соответственно, следуя твоей логике, разное ООП.
M>Как перейти из одного ООП к другому ООП минуя прямую работу с данными?

полиморфизм и инкапсуляция — разные вещи. В своей СУБД Я поддерживаю

— полиморфизм методов (наследование + виртуальные методы)
— полиморфизм интерфейсов
— полиморфизм структуры объекта (одна структура может "притвориться" другой структурой)

Первые два — на уровне инстанциированных экземпляров, третье — напрямую в модели данных.

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

S>Ваши доводы или совершенно неубедительны,
Аргументы кончились? Не нравится — не ешь..

S> или доказывают прямопротивоположную точку зрения.
Это какую и каким образом?

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

S>А может не надо ODMG называть объектной группой ?
Причем здесь ODMG, речь о твоей системе. Вообще я заметил у тебя тяга пытаться разговор менять, когда аргументы кончаются...

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

S> Моя личная практика говорит мне что это у них и у Вас с идеологией проблемы
Безумству храбрых...

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

GZ>Что значит привинчен?

То и значит, что в ООБД данные неразрывно связаны с кодом.

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

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

AVK>То и значит, что в ООБД данные неразрывно связаны с кодом.

А в РБД данные связаны с СП. Какие проблемы? Что в РБД что в ОБД с этим проблем нет.

И еще свои две копейки. В СУБД Cerebrum можно менять сборки не меняя хранилище БД. Формат хранения объектов ваааще никак не связан с реализацией этих объектов в языке программирования.

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


Итак, ОБД по этому вопросу ничем не уступает РБД.

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

S>полиморфизм и инкапсуляция — разные вещи.
Кто бы спорил...

S> В своей СУБД Я поддерживаю
Молодец. А теперь вспомни, что ты там не поддерживаешь. И уж коль мы выяснили, что СУБД у тебя не объектная, а здесь речь идет об ООП, то причем здесь собственно твоя СУБД?

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

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

S>Извините, но у Вас я вообще аргументов не заметил.
Меня всегда поражает способность не замечать неудобные вещи... =)

S> Только декларацию того что ОБД это бесперспективно.
Ну да, при такой избирательности, действительно можно заметить только декларацию. Тем не менее, даже на декларацию ты не подумал дать аргументированного опровержения.

S>Ну не любишь ты ОБД,
Я их не нелюблю. Я просто предпочитаю использовать в работе наиболее подходящий инструмент.
Тем более, как мы выяснили, ООБД здесь непричем.

S> Знаешь, мне с тобой беседовать просто скушно.
Еще бы, сложно смотреть правде в глаза..

S> Ни на один мой тезис о внутреннем устройсве Cerebrum ты не ответил.
Какой смысл рассуждать о внутреннем устройстве при неверной идеологии? Особенно, если тебе даже термины верно использовать неудается.

S> Жалко на такое время тратить.
Сам же критики просил, теперь обижаешься...

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

Д>>если есть данные и есть методы для работы с ними — это уже ООП....
M>Смело... Ну пусть.
M>Далее, в зависимости от задачи, для одних и тех же данных нужны разные методы, соответственно, следуя твоей логике, разное ООП.

а можно поподробнее, как это?

M>Как перейти из одного ООП к другому ООП минуя прямую работу с данными?

Не бывает разных ООП, бывают разные декомпозиции. Одни из них удачные, другие не очень. Нужно выбирать удачные

M>Везет же...

везение здесь ни при чем, я тебя уверяю

Д>>а где именно рассказывал?
M>Re: Файловые системы, файлы, приложения &mdash; устаревшие концепц

Автор: Merle
Дата: 20.04.06

много букв, еле осилил . Насколько я понял, основная и единственная мысль в том, что семантика данных в БД может меняться, а поведение объектов — нет.
Откуда такое ограничение?

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

О пошла конкретика, байкот временно снимается

S>> В своей СУБД Я поддерживаю
M>Молодец. А теперь вспомни, что ты там не поддерживаешь. И уж коль мы выяснили, что СУБД у тебя не объектная, а здесь речь идет об ООП, то причем здесь собственно твоя СУБД?

Это кто выяснил? С этой глупостью только ты тут маешся объектная/необъектная. Все уже давно все выяснили. Хранилище есть? — есть. Объекты C# хранятся? — хранятся. Модель данных есть? — сетевая. — Значить ООСУБД


S>>Первые два — на уровне инстанциированных экземпляров, третье — напрямую в модели данных.
M>То есть, для того чтобы проверить полиморфный метод на соответствие предикату его надо инстанцировать, а значит индексы идут в лес, сколько у нас при этом будет занимать поиск можно хорошо представить.

1. незабываем про пункт 3.
2. ОБД тем и интересны, что обеспечивают методы разработки, которые не требуют никакого поиска вааааще и в том числе никакого поиска объектов на основе предикатов в 90% случаев. В Остальных 10% завсегда есть возможность плавно скатиться к старым проверенным методам поиска аля РБД (с сохранением сетевой модели данных).
3. Никто не мешает динамически обновлять индекс при изменении вычисляемого значения свойства объекта. Волновой алгоритм пропагации изменений это обеспечит с минимальными затратами перформанса (в Cerebrum еще не реализовано.)
4. Мы тут не столько мое изделие обсждаем сколько ваще ОБД против ваще РБД. Я свою БД привожу в пример в тех случаях, когда я уже реализовал то что вы объявляете невозможным.
5. Это у тебя с полиморфизмом какойто детский комплекс его якобы необходимости для ОБД во всех случаях? Когда нужен ОБД должна позволять его реализовать. Когда не нужен — должна позволить проиндексировать поле объекта в стиле РБД. Какие проблемы? Выбор у разработчика.

Итак и по этому пункту ОБД по крайней мере не хуже РБД во всех возможных сценариях. Во многих — лучше и мощнее.

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

AVK>>То и значит, что в ООБД данные неразрывно связаны с кодом.

S>А в РБД данные связаны с СП. Какие проблемы?

Нет, не связаны. Хранимки можно спокойно грохнуть или переписать, не озабачиваясь ни какой совместимостью. Если ООБД позволяет аналогичную операцию, то это никакая не ООБД.

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


AVK>Нет, не связаны. Хранимки можно спокойно грохнуть или переписать, не озабачиваясь ни какой совместимостью. Если ООБД позволяет аналогичную операцию, то это никакая не ООБД.

Моя — позволяет. Ты предлагаешь мне назвать мое изделие "пост объектной БД"?, ну это уш как то слишком )) пусть останется СООБЗ — как это в ее официальном текущем ее названии : Сетевая объектно ориентированная база знаний Cerebrum http://www.shuklin.com/ai/ht/ru/cerebrum — там еще нейронки отдельным модулем прикручены — но это оффтопик в этой ветке.

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

IT>Будут радёмые, куда же без них. Но вот совать ООП куда ни попадя, как то в базы данные или в распределённые среды, где ООП плохо работает, и искать в ООП панацею народ потихонечку прекращает. И это правильно. ООП бесценна на уровне небольших объектных моделей, здесь её роль трудно недооценить. Но глобализм не для ООП. Самодостаточная персистентная распределённая объектная модель мира — это утопия.
А кто сказал что в распределенной среде ООБД плохо живется?

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

AVK>>Нет, не связаны. Хранимки можно спокойно грохнуть или переписать, не озабачиваясь ни какой совместимостью. Если ООБД позволяет аналогичную операцию, то это никакая не ООБД.

S>Моя — позволяет. Ты предлагаешь мне назвать мое изделие "пост объектной БД"?,

Я предлагаю не называть ее объектной БД.

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

S>>Моя — позволяет. Ты предлагаешь мне назвать мое изделие "пост объектной БД"?,

AVK>Я предлагаю не называть ее объектной БД.

Какое название ты считаешь более адекватным?

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

S>О пошла конкретика, байкот временно снимается
Как то ты быстро от своих слов отказываешься...

S>Это кто выяснил?
Я, еще вчера.

S>С этой глупостью только ты тут маешся
Ну, кто чем тут мается, у меня уже тоже сложилось четкое представление...

S> Все уже давно все выяснили.
Во-во.

S> Объекты C# хранятся?
Нет.

S> Модель данных есть?
Причем здесь модель данных?

S>2. ОБД тем и интересны, что обеспечивают методы разработки, которые не требуют никакого поиска вааааще и в том числе никакого поиска объектов на основе предикатов в 90% случаев.
То есть в 90% случаев ООБД не применимы, так как в реальной жизни нужен предикат. Мнене нужен вася пупкин окончивший школу в 2004 году, а не абстрактный объект с гуидом.

S>3. Никто не мешает динамически обновлять индекс при изменении вычисляемого значения свойства объекта.
Не пойдет, сам же писал, объект надо инстанцировать, чтобы полиморфный метод вызвать, то есть до инстанцирования объекта ты не можешь значть значение метода, значит при поиске надо явно инстанцировать кажный объект в коллекции.

S>4. Мы тут не столько мое изделие обсждаем сколько ваще ОБД против ваще РБД.
О чем я и говорю. И если берем честную ООБД, то вспоминаем про инкапсуляцию и индексы отдыхают со 100% гарантией.

S> Я свою БД привожу в пример в тех случаях, когда я уже реализовал то что вы объявляете невозможным.
Я ничего не объявлял невозможным, я четко оговорил область применения подобных систем.

S>5. Это у тебя с полиморфизмом какойто детский комплекс
Скорее дело в том, что у тебя нет понимания того, что такое ООП, а все туда же — ООБД писать...

S> его якобы необходимости для ОБД во всех случаях?
То есть у нас теперь и полиморфизм не так уж в ОО необходим, замечательно. Следующее на очереди у нас, наверное, наследование...
Вот скажи мне, так ли нужно наследование в ООП?

S>Итак и по этому пункту ОБД по крайней мере не хуже РБД во всех возможных сценариях. Во многих — лучше и мощнее.

Значит, вместо реляционки получили сетевую БД, не подходящую для 90% задачь, заплатку для ассоциативных запросов, коих подавляющее большинство в реальных системах, и после этого начинаем говорить о преимуществе и мощи? Забавно, право слово, этож как фанатеть-то надо...

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

Д>а можно поподробнее, как это?
Это у тебя надо спрашивать. Ты такое определение придумал, вот и пляши от него...

Д>Не бывает разных ООП, бывают разные декомпозиции.
Не-не, все в рамках твоего определения.

Д>Одни из них удачные, другие не очень. Нужно выбирать удачные
Ок, удачная декомпозиция для разных задачь по одним и тем же данным будет разная. Как перейти от одной к другой минуя прямую работу с данными?

Д>везение здесь ни при чем, я тебя уверяю
Не надо, не уверяй..

Д>Откуда такое ограничение?
Ответь на первый вопрос.

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

AVK>>Я предлагаю не называть ее объектной БД.

S>Какое название ты считаешь более адекватным?

Не знаю. Надо сидеть и разбираться.

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

S>>О пошла конкретика, байкот временно снимается
M>Как то ты быстро от своих слов отказываешься...

В отличие от некоторых я открыт к компромисам. "Я хозяен своего слова, я его дал, я и обратно забрал"

S>>Это кто выяснил?
M>Я, еще вчера.

Сам что то для себя понапридумывал, а теперь продвигаешь как установленный факт. Ну ну. Если тебе в розовых очках легче — майся дальше.

S>> Объекты C# хранятся?
M>Нет.

Ага, а ты даже проверял? От этого перла я ваще офигел

S>>2. ОБД тем и интересны, что обеспечивают методы разработки, которые не требуют никакого поиска вааааще и в том числе никакого поиска объектов на основе предикатов в 90% случаев.
M>То есть в 90% случаев ООБД не применимы, так как в реальной жизни нужен предикат. Мнене нужен вася пупкин окончивший школу в 2004 году, а не абстрактный объект с гуидом.

У этого васи как раз и будет ИД по которому его можно будет завсегда найти без всяких там предикатов. В 90% искать надо как раз не абстрактного васю выгнанного с школы в 2004 году, а конкретного и определенного, с некоторым ИД. Это даже в 90% реализаций БД для РБД так.

S>>3. Никто не мешает динамически обновлять индекс при изменении вычисляемого значения свойства объекта.
M>Не пойдет, сам же писал, объект надо инстанцировать, чтобы полиморфный метод вызвать, то есть до инстанцирования объекта ты не можешь значть значение метода, значит при поиске надо явно инстанцировать кажный объект в коллекции.

Объект надо инстанциировать чтоб обновить индекс. При изменении объекта через его методы инстанциация нужна по любому. И это то что и требуется. Онто при изменении и будет инстанциирован. И изменяемая в РБД строка тоже будет в RAM загружена. Тут аналогия полная. А вот при поиске ничего лишнего инстанциировать ненужно, т.к. индекс это уже не экземпляры объектов. Нашел по индексу букмарк, по нему или прочел поле объекта напрямую, или провел инстанциирование — в зависимости от конкретной текущей задачи. Что в РБД что в сетевой ОБД — реализация одинаковая. Модели данных разные. Не вижу я тут проблему. Надумал ты ее.

S>>4. Мы тут не столько мое изделие обсждаем сколько ваще ОБД против ваще РБД.
M>О чем я и говорю. И если берем честную ООБД, то вспоминаем про инкапсуляцию и индексы отдыхают со 100% гарантией.

Ну если с твоей точки зрения честная ООБД та, в которой все что тебе бы хотелось чтобы не работало в ООбД не работает — то такая ООБД действительно отдохнет. Только не надо такую надуманную тобой ООБД обобщать на все остальные ООБД. Так я надумаю РБД без ордер бай и нуллов — и буду тебе тыкать статьями Дейта.


S>> Я свою БД привожу в пример в тех случаях, когда я уже реализовал то что вы объявляете невозможным.
M>Я ничего не объявлял невозможным, я четко оговорил область применения подобных систем.

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

S>>5. Это у тебя с полиморфизмом какойто детский комплекс
M>Скорее дело в том, что у тебя нет понимания того, что такое ООП, а все туда же — ООБД писать...

Если догма приоритетней — пусть такое догматичное ООП катится куда подальше. А если приорететнее функциональность — то тудаже с догмами.


M>Вот скажи мне, так ли нужно наследование в ООП?

Желательно но необязательно. Я поддерживаю.
К примеру VB6 ОО язык без наследования. Благодаря adhoc полиморфизму на нем можно реализовать все теже паттерны, что и на C++ с множественным наследованием.

Полиморфизм более желателен чем наследование. Я поддерживаю как структурный так и поведения. Вот без чего в ООП будет грусно — так без полиморфизма.


M>Значит, вместо реляционки получили сетевую БД, не подходящую для 90% задачь, заплатку для ассоциативных запросов, коих подавляющее большинство в реальных системах, и после этого начинаем говорить о преимуществе и мощи? Забавно, право слово, этож как фанатеть-то надо...

И что ты куришь чтоб к таким выводам приходить и так слова собеседников переврать?

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

AVK>Не знаю. Надо сидеть и разбираться.

СООБЗ — это самое близкое к тому что я уже сделал/собираюсь сделать и что я смог сформулировать достаточно коротко.
Если найду более адекватное название — само собой переименую.

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


Д>>Одни из них удачные, другие не очень. Нужно выбирать удачные
M>Ок, удачная декомпозиция для разных задачь по одним и тем же данным будет разная. Как перейти от одной к другой минуя прямую работу с данными?

Сетевая модель, в отличии от иерархической (для иерархической ОМД все твои замечания действительно полностью адекватны) позволяет представлять один и тот же элемент данных одновременно в разных декомпозициях. И кстати, и в отличии от РМД в которой все данные жестко прибиты к кортежам. Чтобы в РМД перейти от одной нарезки (НФ) к другой нужно делать безумные JOINs. Что делает РМД эквивалентной иерархической модели. Тоесть выявленная тобой проблема одинаково присуща как иерархическим так и реляционным моделям. Хотя РМД по сравнению с иерархической выглядит несколько адекватнее.

И в этом случае РМД + РБД отдыхают по сравнению с сетевыми ОМД/ОБД.

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

M>Это у тебя надо спрашивать. Ты такое определение придумал, вот и пляши от него...

нет, не надо у меня спрашивать. Ты сказал:
M>Далее, в зависимости от задачи, для одних и тех же данных нужны разные методы, соответственно, следуя твоей логике, разное ООП.
я просто поинтересовался более подробным объяснением этого высказывания.
Да, для обработки данных у объекта есть разные методы. Если этих методов не хватает, то интерфейс объекта расширяют. Для этого есть масса механизмов, начиная от приплюснутого наследования (далеко не самый удачный вариант), и плюс к этому куча других методов — множественная динамическая классификация, добавление методов "на лету", и т.д. и т.п.
В чем здесь неразрешимая проблема то?

Д>>Не бывает разных ООП, бывают разные декомпозиции.
M>Не-не, все в рамках твоего определения.

да, в его рамках. А в чем проблемы?

M>Ок, удачная декомпозиция для разных задачь по одним и тем же данным будет разная. Как перейти от одной к другой минуя прямую работу с данными?

В чем конкретно будут заключаться различия этих декомпозиций?

M>Не надо, не уверяй..

если у тебя есть в этом сомнения, приведи конкретные примеры задач, которые ну никак не ложатся на объекты. А то меня что-то уже слегка мутит от общих слов.

Д>>Откуда такое ограничение?
M>Ответь на первый вопрос.

а где там вообще вопрос? Это там, где "спроси себя сам", что ли? Честное слово, у меня нет никакого желания играть в Нео и Морфеуса

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

S>Я хозяен своего слова, я его дал, я и обратно забрал
Понятно.

S> Если тебе в розовых очках легче — майся дальше.
Золотые слова.

S>Ага, а ты даже проверял?
Зачем? Ты сам все рассказал.

S>У этого васи как раз и будет ИД по которому его можно будет завсегда найти без всяких там предикатов.
Как я узнаю что этот ID относится именно к этому васе?

S> Это даже в 90% реализаций БД для РБД так.
Что там было про розовые очки?

S> И изменяемая в РБД строка тоже будет в RAM загружена. Тут аналогия полная.
Я не понимаю почему ты все время пытаешься соскочить на реляционку и объяснить, что там точно так же, ты за свою систему ответь.

S> Не вижу я тут проблему. Надумал ты ее.
И еще раз, про розовые очки, определенно, очень удачная фраза...

S>Ну если с твоей точки зрения честная ООБД та,
С моей точки зрения честная ООБД — это та, которая поддерживает, как минимум, наследоване, инкапсуляцию и полиморфизм, в том виде, в котором ее поддерживают современные объектные ЯП.

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

S>Может пост прозевал. Приведешь ссылку?
Легко: Re: Файловые системы, файлы, приложения &mdash; устаревшие концепц

Автор: Merle
Дата: 20.04.06

S>Если догма приоритетней
Дело не в догме, а втом, что если уж упоминаешь в названии своей БД слово "объект" — будь любезен соответствовать.

S>Желательно но необязательно.

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

S> Вот без чего в ООП будет грусно — так без полиморфизма.
Но тем не менее он, по твоим словам, необязателен. Best! И подобную конструкцию, после всего этого ты продолжаеь называть ОО?
Вообщем больше чем на обычную сетевую БД твоя конструкция не тянет.

S>И что ты куришь чтоб к таким выводам приходить и так слова собеседников переврать?
Я правильно понимаю, что некто бесчестный, не найдя подходящих аргументов, обвиняет меня во вранье, чтобы уйти от темы?

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

Д>В чем здесь неразрешимая проблема то?
О неразрешимих проблемах никто не говорит.
Но, как минимум, проблемы в том, что часть данных нужная одной декомпозиции не доступна из другой. Иными словами, для того чтобы любая возможная "декомпозиция", получила доступ ко всем данным, основная "декомпозиция", в которую обернуты данные, должна давать доступ ко всем данным, а это уже не совсем ООП.
Далее, эта самая основная "декомпозиция" работает с данными ограниченным набором методов, и гарантии что это набор методов будет подходить оптимальным образом для всех "декомпозиций" уровнем выше — никто не даст. Следовательно, либо эта самая основная "декомпозиция" должна знать обо всех "декомпозициях" более высокого уровня, что есть нонсенс, либо придется городить дополнительную прослойку оберток и адаптеров.
Можно так работать? — можно. Удобно? — нет. Об этом и речь.

Д>В чем конкретно будут заключаться различия этих декомпозиций?
В том что им нужны разные данные.

Д>если у тебя есть в этом сомнения, приведи конкретные примеры задач, которые ну никак не ложатся на объекты.
Во-первых, не "ну никак", а плохо, а во-вторых, уже приводил. Персистентность, распределенка, отчетность.

Д> А то меня что-то уже слегка мутит от общих слов.
Никто не неволит...

Д>а где там вообще вопрос?
Ну хватит дурака включать...

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

S>Сетевая модель, в отличии от иерархической (для иерархической ОМД все твои замечания действительно полностью адекватны) позволяет представлять один и тот же элемент данных одновременно в разных декомпозициях.
Как уже было замечено, речь здесь не о сетевой модели, а об ООП.

S> И кстати, и в отличии от РМД в которой все данные жестко прибиты к кортежам.
В отличии от реляционки, для того чтобы представить данные в новой декомпозиции, сетевой БД необходимо явно прописать эти связи в БД, в противном случае сетевая БД ничем не лучше иерархической.

S>И в этом случае РМД + РБД отдыхают по сравнению с сетевыми ОМД/ОБД.
Про розовые очки там было очень метко сказано...

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

Д>Я все-таки так и не понял, что именно в ООП плохо работает и при каких условиях?

Не в ООП, а сам(а,о) ООП.

IT>>Самодостаточная персистентная распределённая объектная модель мира — это утопия.

Д>А знаешь, где здесь заключается утопия? В словах "модель мира". Всё остально — вторично.

Думаешь? Давай возьмём в качестве примера интернет. Чем тебе не модель мира, вот где глобализму хоть отбавляй. И ведь работает, и не утопия, но основан не на ООП, хотя где-то местами ООП безусловно с успехом используется.

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

GZ>А кто сказал что в распределенной среде ООБД плохо живется?

А кто сказал что хорошо?

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

M>О неразрешимих проблемах никто не говорит.

значит, про закат ООП было сказано для красного словца?

M>Но, как минимум, проблемы в том, что часть данных нужная одной декомпозиции не доступна из другой. Иными словами, для того чтобы любая возможная "декомпозиция", получила доступ ко всем данным, основная "декомпозиция", в которую обернуты данные, должна давать доступ ко всем данным, а это уже не совсем ООП.

приведи хоть один конкретный пример, который иллюстрирует твои тезисы, тогда и обсудим. А то продираться через нагромождения слов и пытаться воспроизвести ход твоих мыслей я уже устал.

M>Далее, эта самая основная "декомпозиция" работает с данными ограниченным набором методов, и гарантии что это набор методов будет подходить оптимальным образом для всех "декомпозиций" уровнем выше — никто не даст. Следовательно, либо эта самая основная "декомпозиция" должна знать обо всех "декомпозициях" более высокого уровня, что есть нонсенс, либо придется городить дополнительную прослойку оберток и адаптеров.

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

M>Во-первых, не "ну никак", а плохо, а во-вторых, уже приводил. Персистентность, распределенка, отчетность.

персистентность? вау, как интересно! а мужики то и не знают (С)
распределенка? а здесь то вообще какие проблемы?
отчетность, точнее агрегирование данных — это да, некоторые проблемы здесь есть. Но всё тоже можно решить при наличии желания.

Д>> А то меня что-то уже слегка мутит от общих слов.
M>Никто не неволит...

то есть конкретных примеров так и не будет?

M>Ну хватит дурака включать...

просто формулируй мысли по человечески

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

S>>>- инкапсуляция не рекомендуется к применению.
S>>>- для особых случаев допускается бинарная сериализация ЧАСТИ объекта.

IT>>Это уже не OODB, а COODB, где C абревиатура от castrated. Это как раз то о чём говорит Иван, получается ни два, ни полтора. Кастрированная объектная модель и такая же неполноценная база данных.

S>И что же такого важного я не смогу провернуть в такой модели, что можно провернуть в вашей?

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

Твои объекты это фактически примитивные DTO без инкапсуляции и внутреннего состояния.

S>Как раз наоборот. Это вы в своей "полной" модели не сможете сделать многого что я смогу сделать в своей "castrated"

У меня в моей модели нет никаких искусственных ограничений. Вообще никаких. Данные лежат отдельно и обрабатываются специально для этого годами затачиваемыми средствами. А объектная модель во всей своей красе и со всеми своими целыми не насильно отрубленными причиндалами отдельно.

S>Поэтому считаю ваши доводы неубедительной демагогией.

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

S>И на маппинг там время не тратится, и сети поддерживаются по полной, Ну ну.

Время на маппинг вполне сравнимо с сериализацией объектов из твоей ООБД.

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

Д>>Я все-таки так и не понял, что именно в ООП плохо работает и при каких условиях?

IT>Не в ООП, а сам(а,о) ООП.

неважно. Хочу точные данные

Д>>А знаешь, где здесь заключается утопия? В словах "модель мира". Всё остально — вторично.

IT>Думаешь? Давай возьмём в качестве примера интернет. Чем тебе не модель мира, вот где глобализму хоть отбавляй. И ведь работает, и не утопия, но основан не на ООП, хотя где-то местами ООП безусловно с успехом используется.

ну во первых, если интернет — модель, то давай уточним кое-какие вопросы.
Какие аспекты мира он моделирует, какие — нет? Иными словами, насколько полна эта модель?
Каким задачам она служит?

Во вторых, основа интернета — гипертекст — это все равно ООП в чистом виде

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

Д>значит, про закат ООП было сказано для красного словца?
Откуда такой вывод?

Д>приведи хоть один конкретный пример, который иллюстрирует твои тезисы, тогда и обсудим.
Учись мыслить абстрактно..

Д> А то продираться через нагромождения слов и пытаться воспроизвести ход твоих мыслей я уже устал.
Никто не неволит.

Д>либо нужно подумать о том, что интерфейс объектов может меняться с изменением требований к системе. Свежая мысль, не правда ли?
Угу, то есть каждый раз при изменении задачи, переделывать базовые объекты, хотя сами данные не менялись — действительно свежо.

Д>Спроектировать объектную модель классов, "шоб всегда само работало", все равно никогда не получится.
Именно, об этом и речь. Так зачем ее проектировать, если можно хранить сырые данные и накручивать поверх нужные объекты в случае необходимости?

Д>персистентность? вау, как интересно! а мужики то и не знают (С)
Не знаю, что там не знают мужики, а вот проблемы с сохранением объектов сложно не заметить. Добро пожаловать мужикам в реальный мир.

Д>распределенка? а здесь то вообще какие проблемы?
Ну ка — ну ка, как там мужики объекты и вызовы по сети гоняют? В лучшем случае DTO... Это называется — нет проблем?

Д>отчетность, точнее агрегирование данных — это да, некоторые проблемы здесь есть.
То есть, когда ты говорил, что проблем нет — обманывал?

Д>Но всё тоже можно решить при наличии желания.
А кто говорил, что ничего решить нельзя? Просто есть более адекватные способы, чем пытаться сделать все через объекты.

Д>то есть конкретных примеров так и не будет?
Да куда уж конкретнее, все же разжевал, а то что примеры тебя не устраивают, так я не виноват.

Д>просто формулируй мысли по человечески
И так уж человечнее некуда.

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

Д>>>Я все-таки так и не понял, что именно в ООП плохо работает и при каких условиях?
IT>>Не в ООП, а сам(а,о) ООП.
Д>неважно. Хочу точные данные

Точные данные чего? Того что ООП не работает в распределённых системах и в ООБД? Ты понимаешь в чём дело, если нет таких данных, то они никак не могут быть точными. Есть данных, что где-то кто-то когда-то от кого-то слышал или даже видел глазами расказчика про то, что ООП вдруг успешно применился в суперраспределённой среде и ООБД. По таким слухам сложно собрать точные данные, так что извини

Д>ну во первых, если интернет — модель, то давай уточним кое-какие вопросы.
Д>Какие аспекты мира он моделирует, какие — нет? Иными словами, насколько полна эта модель?
Д>Каким задачам она служит?

Интернет — это глобальная распределённая сеть. И глобальная и распределённая, т.е. то о чём ООП может только продолжать мечтать. И заметь, это работает и ни мне ни тебе это не надо доказывать. Мы оба знаем что это так.

Д>Во вторых, основа интернета — гипертекст — это все равно ООП в чистом виде

Точно так же можно сказать, что основа ООП — это машинные коды. Впрочем, я с этим спорить не собираюсь. Как я уже сказал, ООП прекрасно себя чувствует на небольших модельках, где может и должен эффективно применяться. Но только не надо глобализму, и всё у нас получится

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

GZ>Мое IMHO что эпоха ООБД еще не начиналась.

Эта эпоха может начаться только когда закончится эпоха написания кода человеком. Для человека это слишком сложная задача.

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

M>Откуда такой вывод?

ну ты уж определись хотя бы. Или есть непреодолимые проблемы, и тогда ООП действительно ничего хорошего не светит, или их нет.

M>Учись мыслить абстрактно..

излагать неясно запутанные мысли != мыслить абстрактно
если ты не в состоянии сгенерировать простой и ясный пример, который иллюстрирует твои абстракции — значит, никаких абстракций у тебя просто нет
хинт — говорить "Х не работает, потому что я так сказал" за пример проблемы не засчитывается

Д>> А то продираться через нагромождения слов и пытаться воспроизвести ход твоих мыслей я уже устал.
M>Никто не неволит.

я еще не оставил надежду, что за твоими словами есть какой-то смысл

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

объект — это совокупность данных и методов, которые их обрабатывают в соответствии с требованиями. Если требования меняются, то меняются и методы. Тебя в этом что-то удивляет?

Д>>Спроектировать объектную модель классов, "шоб всегда само работало", все равно никогда не получится.
M>Именно, об этом и речь. Так зачем ее проектировать, если можно хранить сырые данные и накручивать поверх нужные объекты в случае необходимости?

сырые данные и так всегда есть. Внутри объектов. Зачем создавать дополнительное представление данных?

M>Не знаю, что там не знают мужики, а вот проблемы с сохранением объектов сложно не заметить. Добро пожаловать мужикам в реальный мир.

с каким конкретно сохранением? Сериализацией в файл? Маппингом объектов на РБД? Сохранением объектов в ОБД? Какую конкретно из них? Какие конкретно проблемы?

M>Ну ка — ну ка, как там мужики объекты и вызовы по сети гоняют? В лучшем случае DTO... Это называется — нет проблем?

У объекта есть данные, их упаковывают, пересылают на другую сторону и создают точно такой же объект. Где ты здесь видишь проблему?

Д>>отчетность, точнее агрегирование данных — это да, некоторые проблемы здесь есть.
M>То есть, когда ты говорил, что проблем нет — обманывал?

проблемы есть, но они есть у существующих реализаций ОБД и существующих реализаций языков. Мы здесь обсуждаем перспективу, не так ли?

M>А кто говорил, что ничего решить нельзя? Просто есть более адекватные способы, чем пытаться сделать все через объекты.

какие? ORM, что ли?

Д>>то есть конкретных примеров так и не будет?
M>Да куда уж конкретнее, все же разжевал, а то что примеры тебя не устраивают, так я не виноват.

я пока еще ни одного не видел, поэтому судить пока не могу

Д>>просто формулируй мысли по человечески
M>И так уж человечнее некуда.

тогда мне даже страшно представить, что будет, если ты включишь генератор флейма

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

GZ>>А кто сказал что в распределенной среде ООБД плохо живется?
IT>А кто сказал что хорошо?
Можешь верить или не верить но именно отчеты и распределенки лучше всего уживаются в распределенной среде по сравнению с чистой реляционкой.
Для реляционки репорты являются проблемой из-за двухмерности. Не зря Кодд придумал OLAP. Вторая проблема в том, что очень сложно обрабатывать сложные случаи типа "если у нас такая сумма, то мы берем следующий коэффициент и по нему высчитываем сумму". Навигационный доступ с ручной обработкой в данном случае более удобен.
Что касается распределенной среды, то распределенность изначально закладывалась в OID. Когда есть OID у тебя нет дубликатов ключей при репликации как понятия. OID может адресовать не строку в базе, а объект находящийся вообще на другом компе. Во многом, подобная распределенность сделана в GemStone. В ней граф объектов может быть и локальным, и удаленным.(некоторые потуги Oracle по кэшированию локальных данных появились только сейчас).

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

IT>Эта эпоха может начаться только когда закончится эпоха написания кода человеком. Для человека это слишком сложная задача.
Скорее немного не так. Когда машина начнет понимать что человек написал. А DLinq уже может интерпретировать и трансформировать такой код. Так что эпоха не начинается, а можно сказать наступила.

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


S>>Может пост прозевал. Приведешь ссылку?
M>Легко: Re: Файловые системы, файлы, приложения &mdash; устаревшие концепц

Автор: Merle
Дата: 20.04.06

Это я ужо читал. В натуре не убеждает. Ну ни на чуть чуть. Может вы и правы в чемто, но по этому посту я этого не вижу.

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

S>3. Никто не мешает динамически обновлять индекс при изменении вычисляемого значения свойства объекта. Волновой алгоритм пропагации изменений это обеспечит с минимальными затратами перформанса (в Cerebrum еще не реализовано.)
Кхм. А что такое "волновой алгоритм пропагации"? Гугл на запросы типа "wave index/tree/map propagation" выдает левые ссылки.

Волновой алгоритм нахождения кратчайшего пути — я знаю. А вот как он относится к индексам?

S>4. Мы тут не столько мое изделие обсждаем сколько ваще ОБД против ваще РБД. Я свою БД привожу в пример в тех случаях, когда я уже реализовал то что вы объявляете невозможным.
Интересны базовые алгоритмы — они определяют скорость работы. У вас есть что-то новое, чего нет в существующих ОО/РБД?

S>5. Это у тебя с полиморфизмом какойто детский комплекс его якобы необходимости для ОБД во всех случаях? Когда нужен ОБД должна позволять его реализовать. Когда не нужен — должна позволить проиндексировать поле объекта в стиле РБД. Какие проблемы? Выбор у разработчика.
Если нет полиморфизма, то ОО "легким движением руки" превращается в РБД.

Наследование реализуется в виде join'ов, а инкапсюляция — с помощью прикладных средств работы с БД. Даже навигационный доступ нормально работает в ORM (см. http://www.hibernate.org ).Что у вас есть принципиально нового?

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

ЗЫ: кстати, а Reiser4 смотрели? Там у них построена FS поверх с поддержкой построения индексов по заданным пользователем критериям (фактически, туда добавить еще движок SQL и будет готовая база), причем FS вполне резво работает на миллионах файлов в одном каталоге. Вот тут я приводил простой benchmark: http://rsdn.ru/Forum/Message.aspx?mid=1710544&amp;only=1

Автор: Cyberax
Дата: 02.03.06

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

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

S>>3. Никто не мешает динамически обновлять индекс при изменении вычисляемого значения свойства объекта. Волновой алгоритм пропагации изменений это обеспечит с минимальными затратами перформанса (в Cerebrum еще не реализовано.)
C>Кхм. А что такое "волновой алгоритм пропагации"? Гугл на запросы типа "wave index/tree/map propagation" выдает левые ссылки.


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


C>Интересны базовые алгоритмы — они определяют скорость работы. У вас есть что-то новое, чего нет в существующих ОО/РБД?

Ну вот идентификация другая. Дальше будет больше но не сразу. Не реализованные фичи я обсуждать не буду.


C>Если нет полиморфизма, то ОО "легким движением руки" превращается в РБД.

РБД это в первую очередь РМД. А вот моя ОБД лежит на сетевой МД. РБД она не может быть ну никак.

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

В РБД есть понятие буукмарк. Это и есть скрыты ОИД. Не понятно кому и чем ОИД мешает, в ОБД если он не мешает в РБД,


C>ЗЫ: кстати, а Reiser4 смотрели? Там у них построена FS поверх с поддержкой построения индексов по заданным пользователем критериям (фактически, туда добавить еще движок SQL и будет готовая база), причем FS вполне резво работает на миллионах файлов в одном каталоге. Вот тут я приводил простой benchmark: http://rsdn.ru/Forum/Message.aspx?mid=1710544&amp;only=1

Автор: Cyberax
Дата: 02.03.06

Неа, на это дело не глядел. Будет время — обязательно погляжу.

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


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

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

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


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

Любят у нас слова переверать. В C# инкапсуляция есть? ЕЕ вам как инкапсуляции хватает?
Моя БД паразитирует на .NET и его возможностях. Можете вы и в среде моей БД пользуясь VS 2003 использовать любимую вами инкапсуляцию Что вам в ней не хватает



MS>Это тоже не объект. Пока вы продолжаете называть ваши необъектные данные объектами вы продолжаете натыкаться на теже самые вопросы и комментарии.

C# экземпляр это что?

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

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

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

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

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

Это смешной тест. Особенно эти "до" и "ок". Я могу за 2 часа написать систему со скоростью сканирования и инстантиирования существенно выше и это ничего не докажет. С каких пор это стало показателем производительности БД? Каким образом проводился тест? 80000 штук в секунду прочитанных объектов. Это что — все разом прочитали и вперед? На большой базе при рандомном чтении предел 100 чтений в секунду. По определению. Потому что время доступа к участку на жестком диске около 10мсек. А вы что там меряли, скорость кэша или скорость линейного чтения объектов типа Object?

А вообще хочу сказать, что ведете вы себя невежливо — сначала вы спрашиваете мнения других, а потом начинаете "тыкать" всем подряд и говорить, что вам плевать на их мнение. Я бы мог с вами обсуждать эту тему, поскольку тоже ей занимаюсь, но вы ведете себя настолько "высокомерно", что ничего конструктивного обсуждать желания нет...

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

S>Любят у нас слова переверать. В C# инкапсуляция есть? ЕЕ вам как инкапсуляции хватает?

Вы меня в переверании обвиняете?
Мне хватает инкапсуляции.

S>Моя БД паразитирует на .NET и его возможностях. Можете вы и в среде моей БД пользуясь VS 2003 использовать любимую вами инкапсуляцию Что вам в ней не хватает

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

MS>>Это тоже не объект. Пока вы продолжаете называть ваши необъектные данные объектами вы продолжаете натыкаться на теже самые вопросы и комментарии.

S>C# экземпляр это что?

Хороший вопрос. И ответ ничего не скажет.

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

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

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

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

MS>Это смешной тест. Особенно эти "до" и "ок". Я могу за 2 часа написать систему со скоростью сканирования и инстантиирования существенно выше и это ничего не докажет. С каких пор это стало показателем производительности БД? Каким образом проводился тест? 80000 штук в секунду прочитанных объектов. Это что — все разом прочитали и вперед? На большой базе при рандомном чтении предел 100 чтений в секунду. По определению. Потому что время доступа к участку на жестком диске около 10мсек. А вы что там меряли, скорость кэша или скорость линейного чтения объектов типа Object?

sequential insert, 200000 instances, AMD 1.7 1400 items/sec, DB file 16M
repeatable sequential scan 200000 instances, 20000000 scans — 80000 items/sec
in both tests transactions are disabled.

MS>А вообще хочу сказать, что ведете вы себя невежливо — сначала вы спрашиваете мнения других, а потом начинаете "тыкать" всем подряд и говорить, что вам плевать на их мнение. Я бы мог с вами обсуждать эту тему, поскольку тоже ей занимаюсь, но вы ведете себя настолько "высокомерно", что ничего конструктивного обсуждать желания нет...

Жаль.

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


MS>Ваша БД не поддерживает механизмы инкапсуляции без проблем. Проблемы вы обозначили. Решить их не смогли и списали на .NET.

ИМХО поддерживает в объеме достаточном для эксплуатации. А проблемы — где их нет. Про технические и идеологические проблемы своей БД я знаю. Много их там. Не было бы — не педалил бы следующую версию