Здравствуйте, Merle, Вы писали:
M>Здравствуйте, GlebZ, Вы писали:
GZ>>Лично мое имхо, что в будущем будут доминировать не реляционки и не ОБД, а xml базы данных. M>С ними та же проблема что и с ООП, слшком жестко заданная структура, которую придется менять при изменении требований...
С чего ты взял что там жестко заданная структура? Как раз слабоструктурированная структура которая даст фору всей реляционке. А самое главное гибкие ссылки.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Re[16]: Файловые системы, файлы, приложения - устаревшие кон
Здравствуйте, GlebZ, Вы писали:
IT>>А что они хранят в этой БД? GZ>Насколько я понял какие-то физические параметры небольшой длины но в огромном количестве. Остальное для того чтобы эти данные обработать.
И скорее всего база работает только в режиме чтения и добавления. Никаких удалений или изменений, правильно?
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[8]: Файловые системы, файлы, приложения - устаревшие конц
Здравствуйте, GlebZ, Вы писали:
GZ>DLinq умеет генерить функциональный граф который можно обработать и получить нормальные селективные условия. Это как раз то, чего сильно не хватало до этого.
В Hibernate все это было еще сто лет назад.
... << RSDN@Home 1.2.0 alpha rev. 646 on Windows XP 5.1.2600.131072>>
Здравствуйте, AndrewVK, Вы писали:
GZ>>DLinq умеет генерить функциональный граф который можно обработать и получить нормальные селективные условия. Это как раз то, чего сильно не хватало до этого.
AVK>В Hibernate все это было еще сто лет назад.
Что было?
... << RSDN@Home 1.2.0 alpha rev. 0>>
Re[10]: Файловые системы, файлы, приложения - устаревшие кон
Здравствуйте, IT, Вы писали:
IT>>>А что они хранят в этой БД? GZ>>Насколько я понял какие-то физические параметры небольшой длины но в огромном количестве. Остальное для того чтобы эти данные обработать.
IT>И скорее всего база работает только в режиме чтения и добавления. Никаких удалений или изменений, правильно?
Ты о concurrency? Там она есть. Прочитай документ, он написан достаточно просто и кратко. Не хочется быть кривым радио.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Re[11]: Файловые системы, файлы, приложения - устаревшие кон
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, GlebZ, Вы писали:
AVK>>>В Hibernate все это было еще сто лет назад. GZ>>Что было?
AVK>Я процитировал.
Не сразу понял что ты имел ввиду. Вопрос в том, как создается данное дерево. В Net оно создается в самом языке. Для Hibernate приходится собирать его практически вручную.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Re[19]: Файловые системы, файлы, приложения - устаревшие кон
Здравствуйте, Sinclair, Вы писали:
S>>тогда поиск в РБД будет O(logШ + logУ + log(Ш'*У')) S>>поиск в ОБД O(logШ + logШ' * logу)
Вообще-то для OБД тут логика несколько неправильная. Если ученики и школы находятся в разных экстентах, то разницы между реляционкой и ОБД нет. Даже если ученики находятся в том же экстенте что и школы, это отнюдь не значит что по ним нельзя делать прямых выборок. Но вот если еще введена операция фильтрации по пути, если этот путь указывает на тот же экстент, то ОБД безусловно выйграет. Так как сложность будет измеряться по самому селективному предикату. Другой вопрос что тут можно попасться на остальных запросах, так как размер одного объекта хранения экстента значительно больше и потребует большего количества чтений с диска.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Re[8]: Файловые системы, файлы, приложения - устаревшие конц
Здравствуйте, GlebZ, Вы писали:
GZ>С чего ты взял что там жестко заданная структура?
С того, что она там жестко задана, в виде дерева с одним корнем.
GZ>Как раз слабоструктурированная структура которая даст фору всей реляционке.
В чем она фору даст?
GZ> А самое главное гибкие ссылки.
И что толку от этих гибких ссылок без поддержки индексов? Структура XML документа задает один наиболее эффективный путь доступа к подветкам, все гибкие ссылки которые в этот путь не укладываются сливают по эффективности негибким...
С точки же зрения реляционки — весь XML очень хорошо укладывается в одну таблицу, что очень хорошо показал MS.
... [RSDN@Home 1.2.0 alpha rev. 619]
Мы уже победили, просто это еще не так заметно...
Re[8]: Файловые системы, файлы, приложения - устаревшие конц
Здравствуйте, GlebZ, Вы писали:
ГВ>>А избыточность XML куда девать? GZ>А кто тебе сказал что данные в xml базе данных лежат в текстовом виде? Это не какой-нибудь парсер.
Да это-то понятно. Но всё равно какая-никакая, но индивидуальная идентификация атрибутов должна быть.
Я имею ввиду вот что.
Например, если у нас есть таблица документов РБД, то данные можно уложить плотно, в соответствии со структурой таблицы. Мы в любом случае будем знать, что, скажем, по смещению 0x21 от физического начала записи начинается поле "дата документа". А вот в слабоструктурированом хранилище придётся к каждому фактическому атрибуту присовокуплять его идентификатор и сущность (или код идентификатора в каком-то словаре, не суть). По сумме это должно дать нехилый оверхед по габаритам или выродиться в РБД.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[12]: Файловые системы, файлы, приложения - устаревшие кон
Здравствуйте, GlebZ, Вы писали:
GZ>Не сразу понял что ты имел ввиду. Вопрос в том, как создается данное дерево. В Net оно создается в самом языке. Для Hibernate приходится собирать его практически вручную.
Это технические детали, не имеющие кардинального значения.
... << RSDN@Home 1.2.0 alpha rev. 646 on Windows XP 5.1.2600.131072>>
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>>>А избыточность XML куда девать? GZ>>А кто тебе сказал что данные в xml базе данных лежат в текстовом виде? Это не какой-нибудь парсер.
ГВ>Да это-то понятно. Но всё равно какая-никакая, но индивидуальная идентификация атрибутов должна быть.
Ну схему то никто не отменял.
ГВ>Я имею ввиду вот что.
ГВ>Например, если у нас есть таблица документов РБД, то данные можно уложить плотно, в соответствии со структурой таблицы. Мы в любом случае будем знать, что, скажем, по смещению 0x21 от физического начала записи начинается поле "дата документа". А вот в слабоструктурированом хранилище придётся к каждому фактическому атрибуту присовокуплять его идентификатор и сущность (или код идентификатора в каком-то словаре, не суть). По сумме это должно дать нехилый оверхед по габаритам или выродиться в РБД.
Нет. Оверхеда здесь особо нет даже для реляционок. Во вторых, можно конечно все держать в одной таблице, только это слишком неоптимально по структуре чтения. А количество чтений и записей, их порядок, пожалуй самые важные параметры говорящие о качестве базы данных. В третьих, кто сказал что так уж плохо, если это будет набор таблиц. Как не пыжся, внизу всегда будет реляционка, благо хранение в большинстве случаев последовательное. Все остальные типы баз — это вопрос надстроек над таблицами и математика их общения. Поэтому не надо присовокуплять(хорошее однако слово, надо будет запомнить).
И третье, у меня не хватает время следить за современными проектами по xml базам, а это было и пока еще популярно не хуже ООДБ и их очень многого я не знаю. Так что все ИМХО.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Re[13]: Файловые системы, файлы, приложения - устаревшие кон
Здравствуйте, AndrewVK, Вы писали:
GZ>>Не сразу понял что ты имел ввиду. Вопрос в том, как создается данное дерево. В Net оно создается в самом языке. Для Hibernate приходится собирать его практически вручную.
AVK>Это технические детали, не имеющие кардинального значения.
Имеющие. Очень даже имеющие. Если говорить о ОДБ, то теперь вполне можно обозначать некоторые методы как возможные предикаты, из них можно будет строить вполне селективные вещи. Sinclair кажется именно этим занимался.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Re[9]: Файловые системы, файлы, приложения - устаревшие кон
Здравствуйте, Merle, Вы писали:
GZ>> А самое главное гибкие ссылки. M>И что толку от этих гибких ссылок без поддержки индексов? Структура XML документа задает один наиболее эффективный путь доступа к подветкам, все гибкие ссылки которые в этот путь не укладываются сливают по эффективности негибким...
Дело в том, что здесь используются именно многомерные индексы. И желательно, чтобы на нем был constraint который указывал бы какого типа нода может быть элементом (некоторые утверждают что в их случае это улучшает работу их оптимизаторов запросов). И кстати, xml давно уже вырос из штанишек дерева и поддерживает ссылки. То есть сетевую модель. M>С точки же зрения реляционки — весь XML очень хорошо укладывается в одну таблицу, что очень хорошо показал MS.
Это с точки зрения реляционки. С точки зрения разработчиков чистых xml баз данных это не совсем так. Они все таки задумываются об оптимизации работы с диском. Поэтому стараются разбивать. (правда кое-кого видел, которые хранили и в одной таблице — но это редкость).
... << RSDN@Home 1.2.0 alpha rev. 0>>
Re[10]: Файловые системы, файлы, приложения - устаревшие кон
Здравствуйте, GlebZ, Вы писали:
GZ>Дело в том, что здесь используются именно многомерные индексы.
Где и кем? Я уже приводил пример сиквела — ребята из MS потратили, по некоторым данным, около восьми лет на исследования, как лучше хранить и индексировать XML, рассматривая R-деревья, Quadtree и прочую экзотику... И в итоге остановились-таки на банальном кластерном B+ по реляционной таблице...
GZ>Это с точки зрения реляционки. С точки зрения разработчиков чистых xml баз данных это не совсем так. Они все таки задумываются об оптимизации работы с диском. Поэтому стараются разбивать. (правда кое-кого видел, которые хранили и в одной таблице — но это редкость).
Ну вот только результатов этой оптимизации с помощю хитрых индексов что-то невидать...
... [RSDN@Home 1.2.0 alpha rev. 619]
Мы уже победили, просто это еще не так заметно...
Re[11]: Файловые системы, файлы, приложения - устаревшие кон
Здравствуйте, Merle, Вы писали:
M>Здравствуйте, GlebZ, Вы писали:
GZ>>Дело в том, что здесь используются именно многомерные индексы. M>Где и кем? Я уже приводил пример сиквела — ребята из MS потратили, по некоторым данным, около восьми лет на исследования, как лучше хранить и индексировать XML, рассматривая R-деревья, Quadtree и прочую экзотику... И в итоге остановились-таки на банальном кластерном B+ по реляционной таблице...
Ага. И в результате получили решение, которое не особо их обременяло в реализации.
GZ>>Это с точки зрения реляционки. С точки зрения разработчиков чистых xml баз данных это не совсем так. Они все таки задумываются об оптимизации работы с диском. Поэтому стараются разбивать. (правда кое-кого видел, которые хранили и в одной таблице — но это редкость). M>Ну вот только результатов этой оптимизации с помощю хитрых индексов что-то невидать...
Знаешь. Для того чтобы можно было квалифицированно что-то сказать, нужно пробовать benchmark. Ни со стороны Microsoft, ни с другой какой-либо стороны, я таких публикаций не видел. Соответсвенно, пока утверждения о самом правильном подходе можно считать голословными.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Re[9]: Файловые системы, файлы, приложения - устаревшие кон
Здравствуйте, Sinclair, Вы писали:
S>>Ок. Давайте подискутируем на эту тему. Меня она очень интересует как разработчика собственной ООСУБД/БЗ S>Давайте. Меня это интересует в той же степени.
Ох, сколько тут оказывается разработчиков ООБД....
S>>В своей ОБД я пришел к следующему. S>>- инкапсуляция не рекомендуется к применению. Поля объекта открыты для доступа независимо от методов самого объекта. К этим полям система может обращаться не инстанциируя сам объект. S>Таким образом, ты спустил ООП в мусорную корзину. Если объекты устроены таким образом, то все преимущества ООП недостижимы, а весь полиморфизм сводится к выбору подходящей хранимой процедуры.
Поддерживаю.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Best Regards. Max.
Re[22]: Файловые системы, файлы, приложения - устаревшие кон
Здравствуйте, Дарней, Вы писали:
Д>Ну во первых, хватит обвинять меня во вранье. Я всего лишь пытаюсь выделить смысл в твоих словесных заграждениях. Д>Во вторых, см пуктом выше. Как вот это твое высказывание следует понимать? Д>Как следует понимать высказывание, что "ООП не работает в распределенных системах"? Если оно не работает, значит, есть какие-то принципиальное нерешаемые проблемы? Или в твоих абстракциях нет места приземленной логике, потому что всё занял возвышеный полет мысли?
Про распределённый ООП вообще-то системы не Иван
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[8]: Файловые системы, файлы, приложения - устаревшие конц
Здравствуйте, GlebZ, Вы писали:
GZ>С чего ты взял что там жестко заданная структура? Как раз слабоструктурированная структура которая даст фору всей реляционке. А самое главное гибкие ссылки.
Я очень сильно сомневаюсь в данном утверждении.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[20]: Файловые системы, файлы, приложения - устаревшие кон
Здравствуйте, GlebZ, Вы писали:
GZ>Здравствуйте, Sinclair, Вы писали:
S>>>тогда поиск в РБД будет O(logШ + logУ + log(Ш'*У')) S>>>поиск в ОБД O(logШ + logШ' * logу) GZ>Вообще-то для OБД тут логика несколько неправильная.
Это, извини, смотря какая ОБД. Если мы храним коллекцию учеников в виде коллекционного свойства ("внутри" объекта школы), то без инстанцирования ничего не выйдет.
Если мы храним учеников в отдельном экстенте, оборудуем ученика ссылкой на школу, а коллекция учеников школы строится путем выполнения backreference (select * from student where schoool = @school), то это полностью эквивалентно РБД. GZ>Если ученики и школы находятся в разных экстентах, то разницы между реляционкой и ОБД нет. Даже если ученики находятся в том же экстенте что и школы, это отнюдь не значит что по ним нельзя делать прямых выборок. Но вот если еще введена операция фильтрации по пути, если этот путь указывает на тот же экстент, то ОБД безусловно выйграет.
Это работает только в том случае, если путь известен. Именно такая штука, насколько мне известно, работает в GemStone. Насчет безусловности я очень сомневаюсь. Для RDBMS этот запрос — всего лишь частный случай; оптимизатор может выбрать любой порядок выполнения join и один из нескольких алгоритмов — все определяется фактической статистикой заполнения данных и параметрами запроса. GZ>Так как сложность будет измеряться по самому селективному предикату.
Я не очень себе представляю, как будет выбран самый селективный предикат. GZ>Другой вопрос что тут можно попасться на остальных запросах, так как размер одного объекта хранения экстента значительно больше и потребует большего количества чтений с диска.
В том-то и дело. Сетевые и иерархические СУБД слили в историческом плане именно потому, что оптимизировали одни запросы в ущерб другим. Умение RDBMS адаптироваться к максимально широкому классу запросов и обеспечило их успех.
При этом обрати внимание на то, что собственно никакие ОО-свойства СУБД в данном контексте никак не задействованы.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Если нам не помогут, то мы тоже никого не пощадим.
Мы уже победили, просто это еще не так заметно...
1.1.4 stable rev. 510
