Здравствуйте, 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>Почему? Кудаже без них, только вот не везде и не всегда с ними удобно.

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

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

GZ>здесь

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

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

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

Здравствуйте, 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 возятся с новой игрушкой. Как дети. Значит что-то кардинальная изюминка в ней есть. А общая идея ведь датируется шестидесятыми.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Здравствуйте, 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: Файловые системы, файлы, приложения — устаревшие концепц

Автор: 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: Файловые системы, файлы, приложения — устаревшие концепц

Автор: 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>И на маппинг там время не тратится, и сети поддерживаются по полной, Ну ну.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Здравствуйте, 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 уже может интерпретировать и трансформировать такой код. Так что эпоха не начинается, а можно сказать наступила.

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

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

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

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

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

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

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

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


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

Автор: 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&only=1

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

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

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

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

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

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

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

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

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

Здравствуйте, 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&only=1

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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


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

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



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

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


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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ну вот о чем я и говорил — ничего особенного — все sequential и не ACID.
Такие тесты совершенно неинтересны.

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


MS>Ну вот о чем я и говорил — ничего особенного — все sequential и не ACID.
MS>Такие тесты совершенно неинтересны.

Тогда б конкретезировали, что интересно лично вам. А так на общий вопрос и ответ общий.

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

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

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

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

S>Тогда б конкретезировали, что интересно лично вам. А так на общий вопрос и ответ общий.

Ну возьмите тесты www.polepos.org и проведите. Вот и посмотрим результаты хотя бы на мелких данных.

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


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

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

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

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

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


MS>Ну возьмите тесты www.polepos.org и проведите. Вот и посмотрим результаты хотя бы на мелких данных.

За линк спасибо! Только он уже стоил всего этого бедлама. В ближайшем времени результатов не обещаю. Сами понимаете почему.

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

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


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

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

Да, я видел. Это как-раз пол беды. А вот ошибочная концепция — это увы.

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

Ну без индексов вы вообще не уедете никуда. Хранилище без поиска вообще не нужно.

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

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

S> Какой тут индекс приват полей? Не пахнет тут им. А индексить надо. И учитывать изменения прецедентов тоже надо.

Учитывать надо изменения полей.

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

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

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

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


MS>Ну без индексов вы вообще не уедете никуда. Хранилище без поиска вообще не нужно.
MS>Ну и что? В других-то объектах есть поля — вот по ним и индексы...
MS>Учитывать надо изменения полей.

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

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

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

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

S>За линк спасибо! Только он уже стоил всего этого бедлама. В ближайшем времени результатов не обещаю. Сами понимаете почему.

Пожалуйста. И сравните потом навскидку с db4o или Perst. Правда без индексов там ничего не светит даже на старте...
Кстати Perst тоже 1 человеком делается в свободное время (а по производительности бьет всех подряд с головой), так что тоже не показатель, что вы 1...

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

IT>Точные данные чего? Того что ООП не работает в распределённых системах и в ООБД? Ты понимаешь в чём дело, если нет таких данных, то они никак не могут быть точными. Есть данных, что где-то кто-то когда-то от кого-то слышал или даже видел глазами расказчика про то, что ООП вдруг успешно применился в суперраспределённой среде и ООБД. По таким слухам сложно собрать точные данные, так что извини
Игорь, угадай на чем построена самая большая в мире база данных(подсказываю, это не РСУБД).

IT>Интернет — это глобальная распределённая сеть. И глобальная и распределённая, т.е. то о чём ООП может только продолжать мечтать. И заметь, это работает и ни мне ни тебе это не надо доказывать. Мы оба знаем что это так.
Во первых, отчего же все меньше баз опубликовано в интернете, и все больше SOA? Реляционка как серьезная распределенная база данных — практически неприменима.
a) она не может делать удобоваримый интерфейс
б) она не может идентифицировать данные
В первом случае получаем проблему использования, во втором случае, получаем большой гемморой с репликацией.
Так что то, что глобально распределенные реляционки удобны (миф).

Д>>Во вторых, основа интернета — гипертекст — это все равно ООП в чистом виде
По моему вы все тут начали путать программирование на ООП, и модель данных ООБД. Это разные вещи в которых совершенно разные проблемы и разные подходы. Это все равно что сравнить утюг и рубашку которую ты гладишь.

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

Д>для начала давай уточним, какие из современных ЯП?
На смолтолк не претендую, достаточно шарпа.

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

Д>фактически, для соответствия ООП требуется всего два пункта — инкапсуляция и полиморфизм (полиморфизм != virtual method).
И? Суть-то в том, что у него инкапсуляции нет полиморфизм тоже странный, а все туда же — "объекты", медом на них намазано что ли?

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

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

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

Д>излагать неясно запутанные мысли != мыслить абстрактно
Это да. Расскажи, заодно, как можно "неясно запутать мысли"...

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

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

Д>объект — это совокупность данных и методов, которые их обрабатывают в соответствии с требованиями. Если требования меняются, то меняются и методы. Тебя в этом что-то удивляет?
Меня это не удивляет, меня удивляет зачем при этом методы хранить вместе с данными, таким образом, чтобы до данных в обход этих методов добраться было нельзя. Ведь хранить данные отдельно гораздо проще и гораздо меньше проблем при изменении.

Д>сырые данные и так всегда есть. Внутри объектов.
Только доступа к ним нет, а мне доступ нужен, чтобы новые объекты создать.

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

Д>с каким конкретно сохранением?
С любым.

Д> Сериализацией в файл?
Да.

Д> Маппингом объектов на РБД?
Да.

Д> Сохранением объектов в ОБД?
Да.

Д> Какие конкретно проблемы?
Везде разные.

Д>Где ты здесь видишь проблему?
В необходимости паковать, создавать промежуточный объект для пересылки, сериализовывать/десериализовывать, ect..

Д>проблемы есть
Я сказал, что у ОО есть проблемы, ты сначала начал возражать, но потом все таки признал. Вот давай на этом и завершим.

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

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

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

S>Это я ужо читал.
Прочитай еще раз, до просветления.

S> В натуре не убеждает. Ну ни на чуть чуть.
Надеяться тебя убедить было бы слишком самонадеяно с моей стороны, но, надеюсь, хотя бы пищю для размышлений я подкинул.

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

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

GZ>Во первых, отчего же все меньше баз опубликовано в интернете, и все больше SOA? Реляционка как серьезная распределенная база данных — практически неприменима.
Кто говорит о распределенности БД? В данном случае речь шла о пригодности ОО к распередленке...

GZ>По моему вы все тут начали путать программирование на ООП, и модель данных ООБД.
Никто ничего путать не начал, просто в данной подветке тема немного поменялась...

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

GZ>>>А кто сказал что в распределенной среде ООБД плохо живется?
IT>>А кто сказал что хорошо?
GZ>Можешь верить или не верить но именно отчеты и распределенки лучше всего уживаются в распределенной среде по сравнению с чистой реляционкой.

И какое это имеет отношение к ООБД?

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

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

Без понятия. К моему стыду я даже не знаю какую базу данных ты меешь ввиду

GZ>Во первых, отчего же все меньше баз опубликовано в интернете, и все больше SOA? Реляционка как серьезная распределенная база данных — практически неприменима.

И при чём тут ООБД? Или у неё здесь есть хоть малейший шанс вырваться вперёд?

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

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

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

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

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

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

существует и давно применяется CORBA. Существует и применяется .NET Remoting, существуют и применяются ООБД.
Так что, значит не работают в принципе? Или ты имел в виду какие-то конкретные проблемы, которые не дают жить и которые принципиально нельзя решить из-за врожденных пороков ООП?

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

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

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

M>На смолтолк не претендую, достаточно шарпа.

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

M>Не обязательный для чего?

необязательный для того, что считать реализацию системы ОО

M>И? Суть-то в том, что у него инкапсуляции нет полиморфизм тоже странный,

прямо-таки совсем нет? Это конечно минус.

M>а все туда же — "объекты", медом на них намазано что ли?

а какие есть варианты лучше?

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

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

для тех, кто в танке, повторю и дополню тезис

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

Д>>излагать неясно запутанные мысли != мыслить абстрактно
M>Это да. Расскажи, заодно, как можно "неясно запутать мысли"...

"неясно" — это наречие, которое относится к глаголу. (С) Учебник русского языка, не помню какой класс.

M>Меня это не удивляет, меня удивляет зачем при этом методы хранить вместе с данными, таким образом, чтобы до данных в обход этих методов добраться было нельзя. Ведь хранить данные отдельно гораздо проще и гораздо меньше проблем при изменении.

Руки перед едой надо мыть. Зубы надо чистить каждый день. Доступ к данным нужно инкапсулировать.
Сокрытие информации — один из фундаментальных принципов построения сложных систем.

M>Только доступа к ним нет, а мне доступ нужен, чтобы новые объекты создать.

какие новые объекты? Зачем тебе для них нужны именно сырые даные?

Д>>Где ты здесь видишь проблему?
M>В необходимости паковать, создавать промежуточный объект для пересылки, сериализовывать/десериализовывать, ect..

и что, это и есть та самая проблема, которая убьет ООП?

Д>>проблемы есть
M>Я сказал, что у ОО есть проблемы, ты сначала начал возражать, но потом все таки признал. Вот давай на этом и завершим.

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

M>Кто сказал ORM? Как раз наоборот, отказаться от всяких ORM и прочих объектов и работать с плоскими данными.

no comments. Еще один романтик каменного века...

shuklin,

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

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

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

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

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

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

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

C большим интересом читаю вашу дискуссию, сам учавствовать не планировал, но...

M>>Вот скажи мне, так ли нужно наследование в ООП?
S>Желательно но необязательно. Я поддерживаю.

Вот это сильно!
На самом деле отличие ООП от объектного программирования, заключается как раз в наследовании. Нет наследования — нет второй буквы "О" в ООП.

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

Но как это все криво! Уж не кривизне ли нам стоит стремиться?

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

Д>существует и давно применяется CORBA. Существует и применяется .NET Remoting,

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

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

Д>существуют и применяются ООБД.

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

Д>Так что, значит не работают в принципе? Или ты имел в виду какие-то конкретные проблемы, которые не дают жить и которые принципиально нельзя решить из-за врожденных пороков ООП?

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

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

Вот опять. Не с применением, а полностью на базе и идеологии ООП. Или всё ещё не улавливаешь разницу?

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

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

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

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

Д>>Так что, значит не работают в принципе? Или ты имел в виду какие-то конкретные проблемы, которые не дают жить и которые принципиально нельзя решить из-за врожденных пороков ООП?

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

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

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

IT>Вот опять. Не с применением, а полностью на базе и идеологии ООП. Или всё ещё не улавливаешь разницу?

Хорошо. Полностью на базе и идеологии ООП. Какие принципиальные проблемы, которые можно избежать при отказе от ООП, ты видишь в данной задаче?

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

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

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

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

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

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

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

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

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

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

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

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

Д>а какие есть варианты лучше?
Зависит от задачи.

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

Д>для тех, кто в танке, повторю и дополню тезис
Тем кто в танке, пора бы прекратить навязывать мне слова, которых я не говорил. И вообще внимательнее читать сообщения.

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

Д>Если есть — приведи список таких проблем и объясни, почему жить с ними нельзя и способов решить их нет.
Эй, в танке, ау! Хватит врать. Я нигде не говорил, что есть "непреодолимые" проблемы — это ты о них все время почему-то твердишь.

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

Д>"неясно" — это наречие, которое относится к глаголу. (С) Учебник русского языка, не помню какой класс.
Не увиливай, я не просил объяснить что такое "неясно", я просил подробно рассказать, как можо осуществить описанное тобой действие.

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

Д>какие новые объекты?
Которые нужны для выполнения новых требований к системе.

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

Д>и что, это и есть та самая проблема, которая убьет ООП?
Цитату, где я говорил, что убъет.

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

Д>no comments. Еще один романтик каменного века...
Угу, мышы плакали, кололись, но продолжали жрать объектный кактус. Вам посолить?

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

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

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

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

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

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

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

зато наща беседа с тобой посвящена именно этой теме

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

нет никакой канонической реализации ООП, на соответствие которой язык можно проверить. Можно сказать, что язык Х реализует ООП. Нельзя сказать, что ООП — это есть реализация ООП в языке Х.

Д>>а какие есть варианты лучше?
M>Зависит от задачи.

опиши хотя бы один.

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

M>Тем кто в танке, пора бы прекратить навязывать мне слова, которых я не говорил. И вообще внимательнее читать сообщения.

M>Цитату, пожалуйста, где я говорил, что ООП ничего хорошего не светит.

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

Д>>Если есть — приведи список таких проблем и объясни, почему жить с ними нельзя и способов решить их нет.
M>Эй, в танке, ау! Хватит врать. Я нигде не говорил, что есть "непреодолимые" проблемы — это ты о них все время почему-то твердишь.

Ну во первых, хватит обвинять меня во вранье. Я всего лишь пытаюсь выделить смысл в твоих словесных заграждениях.
Во вторых, см пуктом выше. Как вот это твое высказывание следует понимать?
Как следует понимать высказывание, что "ООП не работает в распределенных системах"? Если оно не работает, значит, есть какие-то принципиальное нерешаемые проблемы? Или в твоих абстракциях нет места приземленной логике, потому что всё занял возвышеный полет мысли?

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

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

Д>>"неясно" — это наречие, которое относится к глаголу. (С) Учебник русского языка, не помню какой класс.
M>Не увиливай, я не просил объяснить что такое "неясно", я просил подробно рассказать, как можо осуществить описанное тобой действие.

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

Д>>Сокрытие информации — один из фундаментальных принципов построения сложных систем.
M>Ага, правильно. Сами себе создадим трудности, а потом с успехом будем их преодолевать.

то есть для тебя даже фундаментальные принципы построения ПО незнакомы. Ясно, учтем.

M>Которые нужны для выполнения новых требований к системе.

приведи детально описанный пример таких изменений.

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

значит, нужно всего лишь изменить контракт старых объектов.

M>Ok, укажи мне реализацию, где этих проблем нет. В противном случае, раз не смогли сделать подходящую реализацию, значит проблема все таки у ОО.

Если следовать твоей логике, то нет никакого смысла заниматься любыми научными исследованиями. Потому что никто не может показать ни одного работающего примера наноробота, который делает что-либо полезное. Совершенно очевидно, что это невозможно, потому что иначе кто-нибудь бы уже сделал такой пример, разве нет?

Д>>no comments. Еще один романтик каменного века...
M>Угу, мышы плакали, кололись, но продолжали жрать объектный кактус. Вам посолить?

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