Здравствуйте, GlebZ, Вы писали:
ГВ>>Оно уже лет, эдак, 20 рассуждает.
GZ>Лично мое имхо, что в будущем будут доминировать не реляционки и не ОБД, а xml базы данных. Просто по многим параметрам они более похожи на ОБД чем на реляционные базы данных.
Это ты себе как представляешь? Чем это может быть обусловлено?
Я вижу только два отличия "XML" от, скажем, реестра:
1. наличие схемы
2. наличие языка запросов
Причем для настоящего успеха нужно к этому иметь:
3. эффективную систему внутреннего представления XML-данных
4. оптимизатор запросов, способный реализовывать запросы (2) поверх этого представления (3), используя метаданные из (1).

Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Например, если у нас есть таблица документов РБД, то данные можно уложить плотно, в соответствии со структурой таблицы. Мы в любом случае будем знать, что, скажем, по смещению 0x21 от физического начала записи начинается поле "дата документа".
Вообще-то эти представления, мягко говоря, устарели. Во времена Clipper типичным решением была действительно прямоугольная таблица, где можно было точно вычислить положение поля P записи R в файле по формуле header_size + record_size*(R1-1)+offset(P).
На практике оказалось, что для эффективной реализации необходимо и достаточно знать положение фрагмента данных с точностью до одной страницы. Как только мы отказываемся от коцепции "текущей записи", прямоугольность таблицы перестает играть решающее значение.
ГВ>А вот в слабоструктурированом хранилище придётся к каждому фактическому атрибуту присовокуплять его идентификатор и сущность (или код идентификатора в каком-то словаре, не суть). По сумме это должно дать нехилый оверхед по габаритам или выродиться в РБД.
Непонятно, во что именно это должно выродиться. Современные RDBMS построены на том, что
а) есть язык декларативных запросов
б) есть набор низкоуровневых операций, которые выполняются очень эффективно (а их очень мало — table scan, index scan, index seek)
в) есть некоторая алгебра, позволяющая строить из одних операций другие (например, join как комбинация table scan + index seek)
г) есть оптимизатор запросов, который выбирает достаточно оптимальный план выполнения — т.е. набор низкоуровневых операций и алгебраических действий над их результатами.
Таким образом, структура хранилища целиком определяется набором тех самых низкоуровевых операций. Эти операции должны быть ровно такими, чтобы обеспечить приемлемую эффективность алгебры над ними; а необходимая алгебра определяется языком запросов.

Я плохо знаю, как именно реализовали поддержку XML в Yukon — тут Иван больше меня разбирался. Вроде как там внутри что-то похожее на RDBMS, но в точности я не уверен. Опять же, неясно, достигнут ли предел — может быть, отказ от некоторых операций или свойств XML позволит еще улучшить эффективность.

GlebZ wrote:
> C>На сайте Hibernate'а видел
> Врут. Каждый наследник требует своего запроса. Иначе сильный overhead. В
> том же hibernate, можно прямо указать что overhead будет небольшой и
> можно получать данные через join.
А _зачем_ нам каждый наследник в отдельности? Обычно требуется работа
или с отдельными классами или только с базовыми классами, в обоих
случаях отдельные запросы не нужны.

Ну а в вырожденных случаях, все равно, проще все загрузить и профильтровать.

>> > Плохо прочитал, смотри выделенное. И еще дополнительно — типов различных
>> > документов обычно от 10 до 50. Вложить их в одну таблицу нельзя.
> C>Вполне можно:
> Внимательней. Получить документы лежащие в папке. Я нигде не писал что
> документы должны быть определенного типа. Такой задачи не стоит.
А я получил все документы, лежащие в папке. Можно делать с ними дальше
что угодно, например, сделать JOIN по всем типам и вывести результат.

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

GZ>Имеющие. Очень даже имеющие. Если говорить о ОДБ, то теперь вполне можно обозначать некоторые методы как возможные предикаты,

Методы нельзя, только лямбды.

GZ> из них можно будет строить вполне селективные вещи. Sinclair кажется именно этим занимался.

Это можно делать и в Hibernate.

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

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

GZ> Соответсвенно, пока утверждения о самом правильном подходе можно считать голословными.
Ну вот и договорились..

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

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

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

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

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

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

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

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

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

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

я подразумеваю связанные наборы данных, обновление которых требует транзакционности. Так яснее?

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

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

IT>Про распределённый ООП вообще-то системы не Иван

он тоже
Re[9]: Файловые системы, файлы, приложения — устаревшие конц

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

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

M>То есть попытался сменить тему разговора и развести демагогию.

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

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

Ура! это уже намного конструктивнее

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

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

почему?

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

не бывает такой задачи — "хранить данные". Бывает задача "хранить и обрабатывать данные". А данные в совокупности с методами их обработки — это объекты. Насколько часто ты видел полностью нормализованную базу без единой SP или триггера, кстати?

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

Д>Я не менял тему.
Менял...

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

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

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

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

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

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

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

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

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

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

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

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

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

S>>>>тогда поиск в РБД будет O(logШ + logУ + log(Ш'*У'))
S>>>>поиск в ОБД O(logШ + logШ' * logу)
GZ>>Вообще-то для OБД тут логика несколько неправильная.
S>Это, извини, смотря какая ОБД. Если мы храним коллекцию учеников в виде коллекционного свойства ("внутри" объекта школы), то без инстанцирования ничего не выйдет.
Ну, если мы сравниваем системы по достаточно качественным образцам(в реляционке, де факто, это Oracle и MSSQL), то стоит и в OODB брать именно качественные образцы(для меня это Versant и GemStone/S).
GZ>>Так как сложность будет измеряться по самому селективному предикату.
S>Я не очень себе представляю, как будет выбран самый селективный предикат.
По статистике ессно.
GZ>>Другой вопрос что тут можно попасться на остальных запросах, так как размер одного объекта хранения экстента значительно больше и потребует большего количества чтений с диска.
S>В том-то и дело. Сетевые и иерархические СУБД слили в историческом плане именно потому, что оптимизировали одни запросы в ущерб другим. Умение RDBMS адаптироваться к максимально широкому классу запросов и обеспечило их успех.
Только вот не надо мешать OODB и другие виды баз. Хотя данная проблема для OODB существует.

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

S>Это ты себе как представляешь? Чем это может быть обусловлено?
S>Я вижу только два отличия "XML" от, скажем, реестра:
Ты сравниваешь чайник и комбайн. Они не сравнимы не только по мощности, но и по вариантам использования.
S>1. наличие схемы
Мало того. Можно делать схему вручную, можно создавать на основе входящего xml потока. Xml штука достаточно самоописывающаяся.
S>2. наличие языка запросов
Не просто языка запросов, а мощного языка запросов. Результат запроса — это может быть не просто подветка, или значение. Это может быть полностью сгенерированный набор нод или граф. При этом в XQuery кроме работы с путями, поддерживаются реляционный join(сейчас времени нет подсмотреть, но возможно и все стандартные реляционные операции, расширенные вряд ли). XQuery — чрезвычайно мощный язык запросов.
3. Xml может быть графом. В нем есть поддержка ссылок.
S>Причем для настоящего успеха нужно к этому иметь:
S>3. эффективную систему внутреннего представления XML-данных
+1
S>4. оптимизатор запросов, способный реализовывать запросы (2) поверх этого представления (3), используя метаданные из (1).
+1
5. Методы потоковой обработки. В отличие от реляционки, и вставляемый xml и результирующий xml — потоки. Поэтому стараются делать не только методы работы с хранилищем, но и обработку потоков.

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

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

<поскипано>

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

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

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

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

M>Кстати, еще одна иллюстрация передергивания.

да у вас паранойя, господин

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

Новые языки и подходы плодятся каждый день. Одна из довольно интересных фич — динамическая классификация — так и не реализована толком нигде. Так что ты просто не прав, развитие идет вовсю.

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

Ты уж определись, нужно тебе менять функционал или нет. Если нужно, то без изменения кода ты все равно никуда не денешься, и неважно, где он лежит — в базе или вне её.

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

Попробую догадаться. Ты случайно не администрированием баз занимаешься?

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

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

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

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

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

M>Я написал, перечитай внимательно всю эту подветку.

уже. ничего интересного пока не нашел

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

C>GlebZ wrote:
>> C>На сайте Hibernate'а видел
>> Врут. Каждый наследник требует своего запроса. Иначе сильный overhead. В
>> том же hibernate, можно прямо указать что overhead будет небольшой и
>> можно получать данные через join.
C>А _зачем_ нам каждый наследник в отдельности? Обычно требуется работа
C>или с отдельными классами или только с базовыми классами, в обоих
C>случаях отдельные запросы не нужны.
Что значит с базовыми? Один из больших недостатков OODB и ORM — избыточность чтения. Экземпляр должен быть загружен полностью, иначе им пользоваться нельзя(в принципе конечно можно и наполовину, но подобных реализаций в контексте ORM я не видел. Очевидно что слишком сложная будет реализация самого объекта).

C
>>> > Плохо прочитал, смотри выделенное. И еще дополнительно — типов различных
>>> > документов обычно от 10 до 50. Вложить их в одну таблицу нельзя.
>> C>Вполне можно:
>> Внимательней. Получить документы лежащие в папке. Я нигде не писал что
>> документы должны быть определенного типа. Такой задачи не стоит.
C>А я получил все документы, лежащие в папке. Можно делать с ними дальше
C>что угодно, например, сделать JOIN по всем типам и вывести результат.
Ты не получил все документы лежащие в папке. Каждый документ — это разный набор аттрибут. Нет одной таблицы Document. Да даже если и есть, ты не сделаешь join по всем типам. У тебя получатся записи по несколько сот столбцов. Не все базы данных такое держат. К тому же, по 50 джоинам реляционка очень хреново работает. Так что скорее всего, удобоваримого результата ты здесь не получишь.

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

GZ>>Имеющие. Очень даже имеющие. Если говорить о ОДБ, то теперь вполне можно обозначать некоторые методы как возможные предикаты,
AVK>Методы нельзя, только лямбды.
А из лямбд методы вызывать нельзя?

GZ>> из них можно будет строить вполне селективные вещи. Sinclair кажется именно этим занимался.
AVK>Это можно делать и в Hibernate.
Hibernate может разбирать программный код?

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

AVK>>Методы нельзя, только лямбды.
GZ>А из лямбд методы вызывать нельзя?

Можно, но expression tree ты по им не получишь.

GZ>>> из них можно будет строить вполне селективные вещи. Sinclair кажется именно этим занимался.
AVK>>Это можно делать и в Hibernate.
GZ>Hibernate может разбирать программный код?

Собственный QL может. А произвольный код программы рабирать не может и LINQ, это тебе Nemerle нужен.

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

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

Отказ от ООП в данном случае условие необходимое, но не достаточное. Накосячить можно и без ООП без проблем, но с ООП это значительно проще. И при чём тут вообще инетные протоколы? Что же тебя всё время куда-то в сторону тянет.

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

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

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

Мне почему-то понять его слова труда не представляет

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

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

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

Здравствуйте, GlebZ, Вы писали:
S>>Это, извини, смотря какая ОБД. Если мы храним коллекцию учеников в виде коллекционного свойства ("внутри" объекта школы), то без инстанцирования ничего не выйдет.
GZ>Ну, если мы сравниваем системы по достаточно качественным образцам(в реляционке, де факто, это Oracle и MSSQL), то стоит и в OODB брать именно качественные образцы(для меня это Versant и GemStone/S).
Ок, давай посмотрим на GemStone. Как у них записывается вышеупомянутый запрос?
S>>В том-то и дело. Сетевые и иерархические СУБД слили в историческом плане именно потому, что оптимизировали одни запросы в ущерб другим. Умение RDBMS адаптироваться к максимально широкому классу запросов и обеспечило их успех.
GZ>Только вот не надо мешать OODB и другие виды баз. Хотя данная проблема для OODB существует.
Повторюсь: в данном контексте никакие ОО-специфичные свойства не рассматриваются. Все, о чем идет речь — навигация супротив запросов.