Здравствуйте, 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>И что ты куришь чтоб к таким выводам приходить и так слова собеседников переврать?
Я правильно понимаю, что некто бесчестный, не найдя подходящих аргументов, обвиняет меня во вранье, чтобы уйти от темы?