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

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

Здравствуйте, 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>Не смотря на то что ООП, как таковое, уже пережило бурный рост и движется к закату

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

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

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

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

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

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, Вы писали:

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

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

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

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

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

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