GlebZ wrote:
> C>Что вполне логично — основная объектная база используется для хранения
> C>больших объемов сложносвязанных массивных данных. В основных данных не
> C>надо делать поиск по многим таблицам со сложными объединениями, пути
> C>доступа к данным относительно фиксированы и нужны сложные
> C>числодробитильные вычисления на клиентах. В общем, идеальные условия для
> C>ООБД.
> Ты не то посмотрел. Там есть конкретный абзац почему была выбрана
> Objectivity
Ну вообще-то я об этом и сказал

> An object oriented approach seems to be the most
> natural way to model HEP data, where complex many-tomany
> relationships are commonplace.
"сложносвязанных" — в моем сообщении.

> above, the persistency system has to also provide multipetabyte
> scalability.
"массивных".

> Also, the thick-client thin-server
> architecture and distributed features seemed well suited to
> scaling, in contrast with the traditional, server-heavy
> RDBMS approach.
> Последнее предложение наиболее интересное.
"сложные числодробитильные вычисления на клиентах"

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

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

> Только на больших данных для
> увеличения производительности некоторых, особо криминальных, транзакций
> приходится денормализовать, и некоторая возможность ad-hook запросов
> теряется.
Балланс, однако.

> И еще возникает вопрос в том, что такое сложные данные. Один
> пример(достаточно простой) я уже показывал:
> Есть юридические лица. Есть физические лица. У них есть общие аттрибуты,
> есть разные аттрибуты. А у документа — есть свойство подписант, в роли
> которого может выступать и юридическое лицо, и физическое.
> Такое легко решается.
Ну это без проблем делается в РСУБД. Вообще, наследование прекрасно
моделируется join'ами.

> Другой пример, более криминальный: есть папка. В ней лежат документы. У
> каждого из них свой набор аттрибутов. Каким запросом можно получить все
> документы лежащие в конкретной папке?
"SELECT * FROM Document WHERE Document.ParentFolder=blah_blah"? Или я
чего-то не понимаю?

> В принципе такое в реляционной модели вообще не опишешь.
> Но если у тебя объектная модель с
> наследованием, или слабоструктурированная xml, то такое очень просто
> решается. Так что в ограничения реляционки натыкаться приходится
> достаточно часто.
Учти, надо не просто решить, а _быстро_ решить. За логарифмическое
время, иначе на больших объемах будут торррмоза.

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

Д> Если реализация ООП в одном конкретном языке создает...
Я тебя уже дважды просил не менять тему. Прекращай заниматься демагогией. Приведя в пример один конкретный язык я отвечал на совершенно другой вопрос.

Д>А теперь объясни, какие принципиальные проблемы создает применение принципов ООП к этой задаче.
Re: Файловые системы, файлы, приложения — устаревшие концепц

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

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

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

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

Д>покажи пальцем, где и что ты объяснил. Ссылку на сообщение и указание точных слов в нем — в студию!
Re[7]: Файловые системы, файлы, приложения — устаревшие конц

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

...только вот не везде и не всегда с ними (объектами) удобно

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

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

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

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

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

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

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

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

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

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

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

Д>это всё не имеет смысла.
Действительно, но если бы ты не занимался искажением чужих слов, то возможно смысл бы сохранился.

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

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

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

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

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

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

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

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

>> Also, the thick-client thin-server
>> architecture and distributed features seemed well suited to
>> scaling, in contrast with the traditional, server-heavy
>> RDBMS approach.
>> Последнее предложение наиболее интересное.
C>"сложные числодробитильные вычисления на клиентах"
Вообще-то этот абзац я перевел немножко по другому. И тут вообще не говорится о числодробилках.


>> Все правильно. Основной плюс РСУБД — действительно ad-hook запросы в
>> строго нормализованном хранилище.
C>ad-hoc вообще-то
Очепятка.

>> Только на больших данных для
>> увеличения производительности некоторых, особо криминальных, транзакций
>> приходится денормализовать, и некоторая возможность ad-hook запросов
>> теряется.
C>Балланс, однако.
Иногда баланс. А иногда получается схема чрезвычайно напоминающая OODB.

C>Ну это без проблем делается в РСУБД. Вообще, наследование прекрасно
C>моделируется join'ами.
Ты откуда такое узнал? Источник можешь указать?


>> Другой пример, более криминальный: есть папка. В ней лежат документы. У
>> каждого из них свой набор аттрибутов. Каким запросом можно получить все
>> документы лежащие в конкретной папке?
C>"SELECT * FROM Document WHERE Document.ParentFolder=blah_blah"? Или я
C>чего-то не понимаю?
Плохо прочитал, смотри выделенное. И еще дополнительно — типов различных документов обычно от 10 до 50. Вложить их в одну таблицу нельзя.


>> В принципе такое в реляционной модели вообще не опишешь.
>> Но если у тебя объектная модель с
>> наследованием, или слабоструктурированная xml, то такое очень просто
>> решается. Так что в ограничения реляционки натыкаться приходится
>> достаточно часто.
C>Учти, надо не просто решить, а _быстро_ решить. За логарифмическое
C>время, иначе на больших объемах будут торррмоза.
Так в том, то и дело, что при таких вещах в реляционке можно о логарифмическом времени забыть. Здесь нужны многомерные индексы.

GlebZ wrote:
> C>Ну это без проблем делается в РСУБД. Вообще, наследование прекрасно
> C>моделируется join'ами.
> Ты откуда такое узнал? Источник можешь указать?
На сайте Hibernate'а видел

> C>"SELECT * FROM Document WHERE Document.ParentFolder=blah_blah"? Или я
> C>чего-то не понимаю?
> Плохо прочитал, смотри выделенное. И еще дополнительно — типов различных
> документов обычно от 10 до 50. Вложить их в одну таблицу нельзя.
Вполне можно:

1. Выделяем общие для всех документов данные в одну таблицу такого вида:

=========================================================
| DocId | Parent-folder | Creation-date |...
+=======+=====================+=========+================
| 11    | 135           | 01/01/01      |...
+-------+---------------------+--------------------------
|...

2. Делаем для каждого _типа_ документов свою таблицу:

=========================================================
| DocId | Type-specific-field | Type-specific-field I ...
+=======+=====================+==========================
| 11    | blah-blah           | blah-blah-2
+-------+---------------------+--------------------------
|...

Теперь для того, чтобы взять все документы типа "Декларация" делаем так:

SELECT * FROM declaration, document WHERE document.id=declaration.id

Таким образом получаем "наследование" — все документы типа "Декларация"
являются "Документами" и могут "cast'оваться" к ним.

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

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

А что они хранят в этой БД?

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

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

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

Оно уже лет, эдак, 20 рассуждает.

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

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

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

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

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

Д>Смоллток. Схема. Руби.
Д>Некоторые концепции ООП до сих пор еще не реализованы толком ни в одном языке.
Д>этого достаточно?

Не достаточно. Это ты сейчас махнул рукой в сторону и сказал "Там, если надо сходи посмотри". Я не это спрашивал. Что конкретно в этих реализациях по твоему не укладывается в нашу систему абстракций?

IT>>Синхронизация состояния.
Д>а при отсутствии объектов, значит, всё синхронизируется само собой?

Что "всё"? В случае с объектами "всё" — это их состояние. Что ты подразумеваешь под "всё" в случае отказа от объектов?

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

>> C>Ну это без проблем делается в РСУБД. Вообще, наследование прекрасно
>> C>моделируется join'ами.
>> Ты откуда такое узнал? Источник можешь указать?
C>На сайте Hibernate'а видел
Врут. Каждый наследник требует своего запроса. Иначе сильный overhead. В том же hibernate, можно прямо указать что overhead будет небольшой и можно получать данные через join.

>> C>"SELECT * FROM Document WHERE Document.ParentFolder=blah_blah"? Или я
>> C>чего-то не понимаю?
>> Плохо прочитал, смотри выделенное. И еще дополнительно — типов различных
>> документов обычно от 10 до 50. Вложить их в одну таблицу нельзя.
C>Вполне можно:
Внимательней. Получить документы лежащие в папке. Я нигде не писал что документы должны быть определенного типа. Такой задачи не стоит.

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

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

Может уже больше 10 лет. Тем не менее что-то пока не видно абсолютного доминирования распределённых CORBA систем на рынке.

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

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

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

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

IT>Может уже больше 10 лет. Тем не менее что-то пока не видно абсолютного доминирования распределённых CORBA систем на рынке.
Так ты сам, вполне правильно сказал. Тормозит. Я просто поправил что CORBA, как стандарт, поддерживает распределенность.

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

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

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

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

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

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

IT>А что они хранят в этой БД?
Насколько я понял какие-то физические параметры небольшой длины но в огромном количестве. Остальное для того чтобы эти данные обработать.

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

S>>>А я считаю это причиной того, что РБД обречены на провал, а ОБД обречены на успех.
S>>>Время нас рассудит.
ГВ>>Оно уже лет, эдак, 20 рассуждает.
GZ>Лично мое имхо, что в будущем будут доминировать не реляционки и не ОБД, а xml базы данных. Просто по многим параметрам они более похожи на ОБД чем на реляционные базы данных.

А избыточность XML куда девать?

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

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

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

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

IT>Ну если DLing по твоему это шаг вперёд в нужном направлении, то нам ещё долго шагать
DLinq умеет генерить функциональный граф который можно обработать и получить нормальные селективные условия. Это как раз то, чего сильно не хватало до этого.

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

GZ>Лично мое имхо, что в будущем будут доминировать не реляционки и не ОБД, а xml базы данных.
С ними та же проблема что и с ООП, слшком жестко заданная структура, которую придется менять при изменении требований...