Здравствуйте, Merle, Вы писали:
GZ>> Для справки, проект System R — разрабатывался, по моему, в течении 8 лет. С 1972-по 1980. Работа Кодда — 68-69гг. Коренная доработка проводилась еще в течении 80'ых(логическая оптимизация, семантическая оптимизация, System R*). Стало более менее мейнстримом в начале 90-ых. M>Для справки. Возраст иерархических БД гораздо больше реляционных, объектные БД пытаются разработать уже лет пятнадцать, XML-ные лет 5-6. Оракл выпустил первую крайне успешную коммерческую реализацию реляционки года за три-четыре, раньше чем IBM очнулась и начала что-то выпускать на основе System R. M>Так что времени было более чем достаточно.
Времени действительно было достаточно, но в данном случае даже по твоим измерениям. Тот же Oracle стал более менее стабильным к шестой версии(начало 90-ых). Стал мощным и стал более менее похож на нынешний к 7 версии(середина 90-ых). До этого был в ходу всякие Adabas и навигационные базы данных типа DBase(он потом только стал реляционным). То есть рынок реляционнок был очень маленький. Сейчас среди OODB то же самое.
У ООDB — не было ни Кодда ни SystemR. Не было изначально более менее полноценного мат аппарата(кроме как реляционного) ни исследовательский проект, который длился в течении 8 лет. В результате, матаппарат был проработан только в конце 90-ых. Почему я считаю что времени было достаточно, да потому что основные проблемы были уже решены в реляционке. Нужно было всего лишь добавить и переработать существующее. Что и было сделано, но уж очень медленно.
GZ>> А пересчитай на пальцах серьезные коммерческие ДБ и сколько лет было развития до того как они стали серьезными. M>Оракл стал серьезным спустя два-три года после своего появления, при этом это была в принципе первая коммерческая СУБД.
Если Oracle впихнули нескольким военным, это еще не значит коммерческий успех.
GZ>>А то что подмени термины на отношения и кортежи, и многие формулы будут эквивалентные. Законы физики они и в Африке действуют. M>Отсюда делаем вывод, что раз действуют законы реляционки, то это реляционка.
Нет. Повторяться не буду. Я не сам придумал как определяют calculus. Так что жалобы не ко мне, а к математикам.
GZ>>Реляционная модель — строгая модель как и любая другая математическая модель. Все что не входит в ее алфавит, уже не входит в реляционную модель. А алфавит небольшой — аттрибут, кортеж, отношение, да может еще что-то придумать можно(сходу не скажу). И достаточно небольшой набор операций. GZ>> Насколько я знаю, термина связи как таковой там нет. Там только описание трансформаций модели. Там не было в алфавите вложенных таблиц. Отношения все равноправны. Там много чего не было, что сейчас используется. M>Отлично. Так вся структура к которой сводится XML при хранении, чудным образом описывается этим скудным аппаратом. (К слову он не такой уж скудный, там есть много того что сейчас не используется, но не о том речь, суть-то сохранена)
Не используется, потому что от должен быть разный. M>Все что сейчас хоть как-то имеет широкое практическое применение в области БД, построено на реляционной модели, вне зависимости от ее строгости и расширенности.
Если ты говоришь в плане хранения данных, и называешь реляционкой набор таблиц, то да. Но и до реляционных баз данных хранили в таблицах. И что? Сетевые БД тоже хранили в таблицах. Про какую-то из них читал — набор таблиц, и что? Будем считать что сетевые произошли от реляционных, а таблица — есть термин только реляционных БД? Только самое замечательное, что у Кодда вообще не было понятия таблица.
GZ>>Насчет альтернативных команд, как тебе такое: M>А при чем тут команды? Хоть горшком назови... Не смущает, что в третьем шарпе синтаксис очень сильно совпадающий с SQL-м работает, тем не менее, по иерархическим запросам?
Попробую дать простое определение OQL. Это SQL с path. Все. Остальное частности выведенные из данного факта. Так что меня не смущает что в третьем шарпе синтаксис очень похож на OQL, и даже сильно совпадает семантикой. И значительно больше чем SQL.
GZ>>И да и нет. Плоские таблицы удобны потому как хранение у нас двухмерное. Но реляционная алгебра, как и другая алгебра состоит из четырех частей: алфавит, утверждения, аксиомы, правила вывода. Модель абстрактная, описывает законы а не реализацию. Реализацию потом додумывают. Так вот, вводим термин путь, и мы уже за пределами модели. M>Почему это за пределами? Как только мы описываем путь в терминах существующей модели, исчезает необходимость за пределы оной модели выходить..
Да, можно и не выходить. А сказать что это надмодель. Я думаю, что чуваки когда придумывали первый ODMG стандарт, именно так и думали. Ну и все дело испоганили на этом. В агрегации путались и даже реляционки. Одни приколы с sum чего стоит. И чего ждать от аггрегации с путями которые не все могут быть дествительными. Стандарт создавался без матаппарата, а только из-за того что у людей было мнение что можно взять легко за основу реляционный и что-то добавить. Ну не смогли.
GZ>>Это про теорию. А про реализацию могу еще намекнуть, каким образом слабоструктурированный xml будет у тебя индексироваться? M>Ты лучше намекни откуда ты взял, что XML слабоструктурированный... Он на самом деле существенно более структурированный нежели реляционная модель. M>А индексироваться он будет очень просто, как только мы сведем его к реляционке проблем не останется. Собственно так и поступают.
Как бы вопрос относительный. Доводы по поводу слабоструктурированности(по буржуйски semistructed, может я неправильно перевел ). Для xml есть некоторая xpath команда в виде //bla-bla. То есть получить все бла-бла независимо от местоположения. То есть путь к этим объектам мы не знаем, и он может быть любым. И существует достаточно много таких комманд подразумевающих, что местоположение объекта не определено. В случае реляционки любая команда SQL подразумевает о том, что она знает где находятся данные. И свести к реляционке подобную модель и далее оперировать стандартными реляционными операциями не всегда представляется возможным.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, GlebZ, Вы писали:
GZ>>VSS и SVN — тоже по сути хранят данные. Но реляционных решений, я что-то не видал. IT>Source Gear Vault — отличается умом и сообразительностью, и на порядок более высокой производительностью чем вышеобозначенные (особенно первый) товарищи.
Ну и что? Посмотрел я его, ну использует документы как блобье. С таким же успехом можно и в файлах хранить. И насчет VSS особо не гони. След. версия в Бете очень даже ничего. Сильно не смотрел, но очень понравилося policy. Посмотри, может и тебе приглянется.
C>Поддерживает, например можно представить иерархию таким образом: C>1. Корневой узел задается числом 1/2 (т.е. 0.5). C>2. Его левый ребенок задается числом 1/4. C>3. Правый ребенок — числом 3/4. C>4. Левый ребенок левого ребенка корневого узла будет задаваться числом 1/8. C>И так далее рекурсивно.
Нет так не пойдет. Во первых не хочу рекурсивно. Во вторых — это бинарное дерево. А количество детей обычно значительно больше чем два.
>> 3. О том что при сращивании объектной модели и реляционной приходится >> плясать с бубном, уже наверно говорить не стоит.
C>Стоит. Так как хорошие нормализованые модели БД прекрасно ложаться на C>объекты.
Хорошие нормализованные модели БД прекрасно ложаться на объекты. Точнее почти. Во первых полностью нормализованная база в большинстве случаев — чрезвычайный тормоз. Ну а во-вторых, она не полностью совпадает с объектной моделью. Ну например, у нас в объекте письмо есть ссылка адресата, может быть либо на объект гражданин, либо на юридическое лицо реализующее интерфейс IGetAddress возращающий адрес. Но при этом, у объекта существует возможность узнать кто этот объект и все его аттрибуты. То есть, в наличии поведение. В реляционку такое, один в один положить уже не удастся. Надо делать подпорку в виде триггера или других таблиц. И sql запросы усложнятся. Данные != объект с поведением.
Здравствуйте, GlebZ, Вы писали:
IT>>Source Gear Vault — отличается умом и сообразительностью, и на порядок более высокой производительностью чем вышеобозначенные (особенно первый) товарищи. GZ>Ну и что? Посмотрел я его, ну использует документы как блобье. С таким же успехом можно и в файлах хранить.
А как ещё их хранить? Как таблицу номер-символа/код-символа? Зато офигенно реляционно Ты лучше посмотри какие он сервисы предлагает, какую статистику выдаёт и с какой с коростью.
GZ>И насчет VSS особо не гони. След. версия в Бете очень даже ничего. Сильно не смотрел, но очень понравилося policy. Посмотри, может и тебе приглянется.
Я эту хрень пол года использовал на предыдущем проекте. Получше конечно старичка VSS, но в перегруженных сетях так же нещадно тормозит. Файловая система она и в африке файловая. В общем, кроме несерьёзных рюшечек я там ничего особенного не заметил.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, GlebZ, Вы писали:
GZ>Времени действительно было достаточно,
Так и запишем.
GZ> Тот же Oracle стал более менее стабильным к шестой версии(начало 90-ых). Стал мощным и стал более менее похож на нынешний к 7 версии(середина 90-ых).
Нееет. К тому времени он уже сам задавал требования стабильности и мощности, а конкурентноспособным он стал с самого начала. То есть соответствовал всем требованиям он практически на момент своего создания.
Иными словами реляционки стали оправдывать возлагаемые на них надежды практически сразу же после создания опытных образцов. Так что отмазки типа "слишком мало времени прошло", для XML баз и, тем более, объектных, уже не канают.
Времени прошло, как ты сам заметил, вполне достаточно, даже с учетом инертности рынка.
GZ>У ООDB — не было ни Кодда ни SystemR.
Это их личные проблемы. Чисто математически теория графов будет по старше реляционной, однако не XML, не OODB это не помогло, видать не спроста....
GZ>Не было изначально более менее полноценного мат аппарата(кроме как реляционного) ни исследовательский проект, который длился в течении 8 лет.
При чем тут исследовательский проект и мат аппарат? Мат аппарат теории графов в несколько раз старше реляционного, а Оракл создавался безовсякой оглядки на System R, только по нескольким публичным работам Кодда. Так что эти отмазки тоже не канают.
GZ> Что и было сделано, но уж очень медленно.
Что-что было сделано?
GZ>Если Oracle впихнули нескольким военным, это еще не значит коммерческий успех.
Оракл впихнули военным еще до того как он стал коммерческим.
GZ>Нет. Повторяться не буду. Я не сам придумал как определяют calculus. Так что жалобы не ко мне, а к математикам.
Причем здесь математики? если что-то выглядит как яблоко и имеет вкус яблока, значит это яблоко.
GZ>Если ты говоришь в плане хранения данных, и называешь реляционкой набор таблиц, то да.
Нет, я говорю в плане операций над данными. Физически происходит выборка множества кортежей из отношения по определенным значениям атрибутов, и это реляционка в читом виде, а уж навесить на это можно все что угодно в силу ее, реляционки, универсальности.
GZ> И что? Сетевые БД тоже хранили в таблицах. Про какую-то из них читал — набор таблиц, и что?
На заборе тоже написано...
GZ>Только самое замечательное, что у Кодда вообще не было понятия таблица.
А у кого оно было?
GZ>Попробую дать простое определение OQL. Это SQL с path. Все.
Что же он тогда так убого выглядит? Даже по сравнению с SQL...
GZ>Остальное частности выведенные из данного факта.
Значит ребята фигово поработали...
GZ>Так что меня не смущает что в третьем шарпе синтаксис очень похож на OQL, и даже сильно совпадает семантикой. И значительно больше чем SQL.
А вот этого вот не заметил.
GZ>Да, можно и не выходить. А сказать что это надмодель. Я думаю, что чуваки когда придумывали первый ODMG стандарт, именно так и думали.
Все было наоборот, чуваки, когда придумывали ODMG вообще ни о чем не думали и в последюю очередь они думали о реляционной теории и о том чтобы ее придерживаться. Первое, что они сделали — это забили на нее большой болт.
GZ>Как бы вопрос относительный. Доводы по поводу слабоструктурированности(по буржуйски semistructed, может я неправильно перевел ). Для xml есть некоторая xpath команда в виде //bla-bla. То есть получить все бла-бла независимо от местоположения. То есть путь к этим объектам мы не знаем, и он может быть любым. И существует достаточно много таких комманд подразумевающих, что местоположение объекта не определено.
Так есть путь или нет? Или он может быть любым? И что такое любой путь? Помоему ты просто в терминах запутался...
GZ> В случае реляционки любая команда SQL подразумевает о том, что она знает где находятся данные.
Да ладно? Точно знает? А XPath или XQuery значит не знает? Зашибись..
Любой запрос, во всех системах предполагает, что в таблице (в случае SQL) или в документе (XML) находится объект, со значением XXX в атрибуте YYY (SQL) или узел MMM по пути NNN (XML), что при взгляде с колокольни реляционного движка обслуживающего всю эту механику, говоря простым русским словом — абсолютно монопенисуально, так как узел MMM по пути NNN абсолютно однозначно отображается в реляционные XXX со значением YYY.
GZ> И свести к реляционке подобную модель и далее оперировать стандартными реляционными операциями не всегда представляется возможным.
Как видишь с возможностями у реляционки проблем нет, что собственно и подтверждено соответствующими теореммами.
И, как ты верно заметил, реляционная модель очень близка к реальному физическому размещению данных, и физические способы доступа к оным данным очень близки реляционным абстракциям, а свою эффективность реляционка уже доказала. Таким образом для разработки эффективного механизма управления любыми моделями данных, достаточно свести эти модели к реляционным, что собственно и происходит.
Здравствуйте, GlebZ, Вы писали:
GZ>Ну и что? Посмотрел я его, ну использует документы как блобье.
Хочешь сказать, что другие БД используют их по другому? Интересно как?
GZ> С таким же успехом можно и в файлах хранить.
И метаданные об этих документах тоже в файлах?
GZ> И насчет VSS особо не гони. След. версия в Бете очень даже ничего.
Та же конструкция только в профиль, принципиально они ничего не поменяли. Полноценный VCS они сделали в TFS-е и, что характерно, на реляционном движке.
GlebZ wrote:
> C>Поддерживает, например можно представить иерархию таким образом: > C>1. Корневой узел задается числом 1/2 (т.е. 0.5). > C>2. Его левый ребенок задается числом 1/4. > C>3. Правый ребенок — числом 3/4. > C>4. Левый ребенок левого ребенка корневого узла будет задаваться > числом 1/8. > C>И так далее рекурсивно. > Нет так не пойдет. Во первых не хочу рекурсивно.
Представляйте числа в виде рациональных чисел, то есть прямо так и
хранить в базе числитель и знаменатель. Глубина получится вполне
достаточная.
> Во вторых — это бинарное дерево. А количество детей обычно значительно > больше чем два.
Решается элементарно — делить в каждый шаг не на два, а на количество
детей. Хотя дерево обычно можно заменить бинарным.
> C>Стоит. Так как хорошие нормализованые модели БД прекрасно ложаться на > C>объекты. > Хорошие нормализованные модели БД прекрасно ложаться на объекты. > Точнее почти. Во первых полностью нормализованная база в большинстве > случаев — чрезвычайный тормоз.
Не совсем — у нас есть база в пятой нормальной форме (прям как по
учебнику ). Получилась после нормализации старой базы — так с ней
работать намного быстрее все стало.
> Ну а во-вторых, она не полностью совпадает с объектной моделью. Ну > например, у нас в объекте письмо есть ссылка адресата, может быть либо > на объект гражданин, либо на юридическое лицо реализующее интерфейс > IGetAddress возращающий адрес. Но при этом, у объекта существует > возможность узнать кто этот объект и все его аттрибуты.То есть, в > наличии поведение.
Ну и в объектах юридических лиц спокойно делаем нужные нам действия.
> В реляционку такое, один в один положить уже не удастся. Надо делать > подпорку в виде триггера или других таблиц. И sql запросы усложнятся. > Данные != объект с поведением.
Я уж не говорю, что триггеры к реляционной модели никак не относятся.
Andrei N.Sobchuck wrote:
> C>реляционную BerkeleyDB. У них даже схема данных была нарисована в доке. > Это каким боком словарь ("ключ-значение") реляционка?
Если есть хотя бы два словаря со связанными ключами — то уже реляционка.
А они в Subversion'е есть.
Здравствуйте, Merle, Вы писали:
GZ>>Времени действительно было достаточно, M>Так и запишем.
Для OODB в виде 1 манифеста, да. Но я не говорил об XML базах.
GZ>> Тот же Oracle стал более менее стабильным к шестой версии(начало 90-ых). Стал мощным и стал более менее похож на нынешний к 7 версии(середина 90-ых). M>Нееет. К тому времени он уже сам задавал требования стабильности и мощности, а конкурентноспособным он стал с самого начала. То есть соответствовал всем требованиям он практически на момент своего создания.
Ну и где ты такое прочитал? Ссылку.
Я знал людей кто работал с пятеркой. Глючнее базу чем Oracle трудно было найти. Но зато эти же люди очень хорошо отзывались об Адабасе. M>Иными словами реляционки стали оправдывать возлагаемые на них надежды практически сразу же после создания опытных образцов. Так что отмазки типа "слишком мало времени прошло", для XML баз и, тем более, объектных, уже не канают. В 74 году(через пять лет после выпуска статьи Кодда) реляционки были только на бумаге. А XML базы уже существуют. M>Времени прошло, как ты сам заметил, вполне достаточно, даже с учетом инертности рынка.
С учетом инертности рынка, нет.
GZ>>У ООDB — не было ни Кодда ни SystemR. M>Это их личные проблемы. Чисто математически теория графов будет по старше реляционной, однако не XML, не OODB это не помогло, видать не спроста....
А причем тут теория графов? Собственно если говорить о теории графов, то нахождение оптимального плана за линейное время в РСУБД, так и не решена. А что касается самой OODB модели, то теория графов непричем.
GZ>>Не было изначально более менее полноценного мат аппарата(кроме как реляционного) ни исследовательский проект, который длился в течении 8 лет. M>При чем тут исследовательский проект и мат аппарат? Мат аппарат теории графов в несколько раз старше реляционного, а Оракл создавался безовсякой оглядки на System R, только по нескольким публичным работам Кодда. Так что эти отмазки тоже не канают.
Откуда информация? Тебе показать список опубликованных работ разработчиков SystemR? Статью в которой они опубликовали BNF сиквела(о чем потом сожалели разработчики)? Oracle изначально делался во время System/R и использовал результаты SystemR. Единственное что им не удалось, это унифицировать номера ошибок. Известная история когда ораклоидам явно отказали в предоставлении информации.
GZ>> Что и было сделано, но уж очень медленно. M>Что-что было сделано?
Из законченных решений мне я видел работы Fegaras и Cherniack and Zdonik. Наверняка есть еще что-то. Если о чем-то не знаешь, необязательно что этого нет.
GZ>>Нет. Повторяться не буду. Я не сам придумал как определяют calculus. Так что жалобы не ко мне, а к математикам. M>Причем здесь математики? если что-то выглядит как яблоко и имеет вкус яблока, значит это яблоко.
Идешь — блестит, подходишь — блестит, берешь — блестит, укусил — дерьмо. Мораль — не все золото что блестит. Проблема в том, что может и выглядит для тебя это яблоком, потому что укусить не додумался.
GZ>>Если ты говоришь в плане хранения данных, и называешь реляционкой набор таблиц, то да. M>Нет, я говорю в плане операций над данными. Физически происходит выборка множества кортежей из отношения по определенным значениям атрибутов, и это реляционка в читом виде, а уж навесить на это можно все что угодно в силу ее, реляционки, универсальности.
Ты описал только проекцию. А операций значительно больше. И конгломерат этих операций предоставляет возможность трансформировать модель из одного реляционного вида в другую. Если твоя возможность только в том, что бегать курсором по таблицам, то это совсем не цель реляционной модели.
GZ>>Только самое замечательное, что у Кодда вообще не было понятия таблица. M>А у кого оно было?
У всех остальных. И в том числе, тех кто реализовывал реляционки, и тех кто просто хранил такие структуры в файле или ОЗУ. Таблица всего лишь структура которая не обязательно принадлежит реляционной модели. Подробности у Дейта.
GZ>>Попробую дать простое определение OQL. Это SQL с path. Все. M>Что же он тогда так убого выглядит? Даже по сравнению с SQL...
К сожалению, не так убого.
GZ>>Остальное частности выведенные из данного факта. M>Значит ребята фигово поработали...
Да нет. Они ставили целью похожесть на SQL. Они этого добились. Некоторые вещи просто сократились.
GZ>>Так что меня не смущает что в третьем шарпе синтаксис очень похож на OQL, и даже сильно совпадает семантикой. И значительно больше чем SQL. M>А вот этого вот не заметил.
Тебе выслать BNF?
GZ>>Да, можно и не выходить. А сказать что это надмодель. Я думаю, что чуваки когда придумывали первый ODMG стандарт, именно так и думали. M>Все было наоборот, чуваки, когда придумывали ODMG вообще ни о чем не думали и в последюю очередь они думали о реляционной теории и о том чтобы ее придерживаться. Первое, что они сделали — это забили на нее большой болт.
Теперь какая разница. Что сделано, то сделано.
GZ>>Как бы вопрос относительный. Доводы по поводу слабоструктурированности(по буржуйски semistructed, может я неправильно перевел ). Для xml есть некоторая xpath команда в виде //bla-bla. То есть получить все бла-бла независимо от местоположения. То есть путь к этим объектам мы не знаем, и он может быть любым. И существует достаточно много таких комманд подразумевающих, что местоположение объекта не определено. M>Или он может быть любым?
Именно.
GZ>> В случае реляционки любая команда SQL подразумевает о том, что она знает где находятся данные. M>Да ладно? Точно знает? А XPath или XQuery значит не знает? Зашибись..
XPath точно нет. Для него xml — поток. M>Любой запрос, во всех системах предполагает, что в таблице (в случае SQL) или в документе (XML) находится объект, со значением XXX в атрибуте YYY (SQL) или узел MMM по пути NNN (XML), что при взгляде с колокольни реляционного движка обслуживающего всю эту механику, говоря простым русским словом — абсолютно монопенисуально, так как узел MMM по пути NNN абсолютно однозначно отображается в реляционные XXX со значением YYY.
В любой реляционке есть словарь который может подсказать где и как лежат те или иные данные. Но не во всех xml существует схема с подсказками. XML можно выполнить как поток который подается на вход, и на выходе получаем результат. Разницу между потоком и реляционным хранилищем улавливаешь? Каким образом ты представляешь себе выполнение такого запроса на реляционке //table1/*/table3?
GZ>> И свести к реляционке подобную модель и далее оперировать стандартными реляционными операциями не всегда представляется возможным. M>Как видишь с возможностями у реляционки проблем нет, что собственно и подтверждено соответствующими теореммами.
Не подтверждено. У реляционной модели нет понятия связей. А без такого понятия xml уместить в реляционке без потери семантики или нельзя или избыточно. M>И, как ты верно заметил, реляционная модель очень близка к реальному физическому размещению данных, и физические способы доступа к оным данным очень близки реляционным абстракциям, а свою эффективность реляционка уже доказала.
Да. M>Таким образом для разработки эффективного механизма управления любыми моделями данных, достаточно свести эти модели к реляционным, что собственно и происходит.
Нет. Не любыми. Можешь привести цифры какие накладные расходы происходят при хранении xml в реляционной модели в SQL2005 и почему они все таки хранят xml в CLOB? Можешь ответить на вопрос Версионость записей в БД
Здравствуйте, Cyberax, Вы писали:
>> Во вторых — это бинарное дерево. А количество детей обычно значительно >> больше чем два.
C>Решается элементарно — делить в каждый шаг не на два, а на количество C>детей. Хотя дерево обычно можно заменить бинарным.
В результате мы получим предопределенное количество детей. К тому же, в большинстве случаев, иерархии вширь значительно больше чем в глубину.
C>Не совсем — у нас есть база в пятой нормальной форме (прям как по C>учебнику ). Получилась после нормализации старой базы — так с ней C>работать намного быстрее все стало.
Обычно все наоборот. Исключение может быть если изначально база была спроектирована неправильно.
>> Ну а во-вторых, она не полностью совпадает с объектной моделью. Ну >> например, у нас в объекте письмо есть ссылка адресата, может быть либо >> на объект гражданин, либо на юридическое лицо реализующее интерфейс >> IGetAddress возращающий адрес. Но при этом, у объекта существует >> возможность узнать кто этот объект и все его аттрибуты.То есть, в >> наличии поведение.
C>Почему же, все прекрасно ложится. C>Делаем полиморфный mapping по дискриминатору: C>http://www.hibernate.org/hib_docs/v3/reference/en/html/inheritance.html#inheritance-tableperconcreate-polymorphism C>http://www.hibernate.org/hib_docs/v3/reference/en/html/queryhql.html#queryhql-polymorphism
C>Ну и в объектах юридических лиц спокойно делаем нужные нам действия.
А теперь смотрим на все это со стороны реляционки, ну например на ссылочную целостность. C>Я уж не говорю, что триггеры к реляционной модели никак не относятся.
Угадал. Это мера вынужденная. Универсальной функции не существует. Как и полного универсализма реляционки.
Здравствуйте, Cyberax, Вы писали:
C>Andrei N.Sobchuck wrote:
>> C>реляционную BerkeleyDB. У них даже схема данных была нарисована в доке. >> Это каким боком словарь ("ключ-значение") реляционка?
C>Если есть хотя бы два словаря со связанными ключами — то уже реляционка. C>А они в Subversion'е есть.
А вместо Кодда должен быть человек который придумал использовать два hashtable в одной программе.
Здравствуйте, GlebZ, Вы писали:
GZ>>>Времени действительно было достаточно, M>>Так и запишем. GZ>Для OODB в виде 1 манифеста, да. Но я не говорил об XML базах.
Так ты разберись о чем ты говоришь.
GZ>Ну и где ты такое прочитал? Ссылку.
В википедии и на сайте оракла.
GZ>Я знал людей кто работал с пятеркой. Глючнее базу чем Oracle трудно было найти. Но зато эти же люди очень хорошо отзывались об Адабасе.
Это личные проблемы этих людей, против фактов продаж и работающих систем — не попрешь.
M>>Это их личные проблемы. Чисто математически теория графов будет по старше реляционной, однако не XML, не OODB это не помогло, видать не спроста.... GZ>А причем тут теория графов?
При том, что и XML и OODB и прочие иерархические конструкции основаны на теории графов.
GZ>Откуда информация?
Из публичных источников.
GZ>Статью в которой они опубликовали BNF сиквела(о чем потом сожалели разработчики)?
Да кому сдался BNF? BNF это исключительно синтаксис, по одному BNF-у ты систему не построишь. Это была чисто маркетинговая промашка, но ни как она не помогла Ораклоидам в плане реализации, у них к томц времени свой язык был, очень не плохо работающий.
GZ>Oracle изначально делался во время System/R и использовал результаты SystemR.
Оракл стал выполнять гос-заказы, когла System R был еще в глубокой теории, и что-то мне не верится в безмерную щедрость IBM раздававшую нахаляву подробности своей закрытой системы. К слову, про внутренности оптимизатров до сих пор мало что толком известно широкой общественности. Так что Оракл был проект вполне себе независимый.
GZ>Из законченных решений мне я видел работы Fegaras и Cherniack and Zdonik. Наверняка есть еще что-то.
И что толку от этих работ? Где реально работающие системы?
GZ> Проблема в том, что может и выглядит для тебя это яблоком, потому что укусить не додумался.
Я же пишу "вкус яблока". Если тебе этот вкус не нравится — это другой вопрос, но против истины не попрешь..
GZ>Ты описал только проекцию.
Тебе что, все расписывать надо? Я просто проиллюстрировал для наглядности.
GZ>У всех остальных.
Не было ни у кого. Слава байту у всех была одна и та же терминология.
GZ> Таблица всего лишь структура которая не обязательно принадлежит реляционной модели. Подробности у Дейта.
Если таблицей называть структуру, которая удовлетворяет 1НФ, и над которой определены операции реляционной алгебры, то она таки принадлежит реляционной модели. Подробности можешь смотреть у кого угодно, от Бойса с Коддом и Греем, до Дейта с Бернстайном и Уидомом.
GZ>>> В случае реляционки любая команда SQL подразумевает о том, что она знает где находятся данные. M>>Да ладно? Точно знает? А XPath или XQuery значит не знает? Зашибись.. GZ>XPath точно нет. Для него xml — поток.
Да какая, блин, разница. Да и не факт что поток, от реализации зависит.
GZ>В любой реляционке есть словарь который может подсказать где и как лежат те или иные данные.
Какой словарь?!!! Нет никакого словаря. Никто никому ничего не подсказывает — это все детали реализации.
В реляционке есть отношение, весь XML сводится к отношениям как два байта переслать, все.
GZ> Но не во всех xml существует схема с подсказками.
Да не нужна она.
GZ> XML можно выполнить как поток который подается на вход, и на выходе получаем результат. Разницу между потоком и реляционным хранилищем улавливаешь?
Нет, не улавливаю. Потому что нет никакого потока. Поток это реализация.
GZ>Каким образом ты представляешь себе выполнение такого запроса на реляционке //table1/*/table3?
Нету ткаого запроса в реляционке один документ — одно отношение.
GZ>Не подтверждено. У реляционной модели нет понятия связей. А без такого понятия xml уместить в реляционке без потери семантики или нельзя или избыточно.
Так нельзя или избыточно? И кого кроме тебя волнует какая-то мифическая избыточность реляционки, даже если она есть?
Еще раз. В реляционку взаимнооднозначно можно запихнуть любую иерархическую конструкцию, в том числе и XML, все.
GZ>Нет. Не любыми. Можешь привести цифры какие накладные расходы происходят при хранении xml в реляционной модели в SQL2005 и почему они все таки хранят xml в CLOB?
Кто тебе сказал, что они хранят это дело в CLOB? В SQL 2005 XML индексируется и раскладывается в реляционную таблицу. Для работы с иерархиями используется так любимый многими алгоритм Nested Sets, некоторым образом модифицированный для оптимизации изменения дерева.
GZ> Можешь ответить на вопрос Версионость записей в БД
GlebZ wrote:
> Не подтверждено. У реляционной модели нет понятия связей. А без такого > понятия xml уместить в реляционке без потери семантики или *нельзя* > или *избыточно*.
Эээ... Вообще-то, "relation" переводится как "отношение, связь". Способ
эффективно представить дерево в РБД — я уже привел.
GlebZ wrote:
> C>Если есть хотя бы два словаря со связанными ключами — то уже > реляционка. > C>А они в Subversion'е есть. > А вместо Кодда должен быть человек который придумал использовать два > hashtable в одной программе.
Заслуга Кодда в том, что он смог построить теоретическую базу для двух
табличек в программе.
GlebZ wrote:
> C>Решается элементарно — делить в каждый шаг не на два, а на количество > C>детей. Хотя дерево обычно можно заменить бинарным. > В результате мы получим предопределенное количество детей.
Нет, рассказать как сделать произвольное число?
> К тому же, в большинстве случаев, иерархии вширь значительно больше > чем в глубину.
Ну и что.
Открою секрет — именно так, как я сказал, и строятся индексы в XMLных БД.
> C>Не совсем — у нас есть база в пятой нормальной форме (прям как по > C>учебнику ). Получилась после нормализации старой базы — так с ней > C>работать намного быстрее все стало. > Обычно все наоборот. Исключение может быть если изначально база была > спроектирована неправильно.
Обычно все как раз прямо. Так как 5 НФ позволяет строить алгоритмически
более эффективные запросы (отсутствия аномальностей, которые есть в
меньших НФ).
> C>Ну и в объектах юридических лиц спокойно делаем нужные нам действия. > А теперь смотрим на все это со стороны реляционки, ну например на > ссылочную целостность.
Здравствуйте, Merle, Вы писали:
GZ>>Ну и где ты такое прочитал? Ссылку. M>В википедии и на сайте оракла.
OK — экскурс
Larry Ellison founded Software Development Laboratories in 1977. In 1979 SDL changed its company-name to Relational Software, Inc. (RSI) and introduced its product Oracle V2 as an early commercially-available relational database system. The version did not support transactions, but implemented the basic SQL functionality of queries and joins. (RSI never released a version 1 — instead calling the first version version 2 as a marketing gimmick.) Да уж. Такое базой данных назвать трудно.
In 1983, RSI in its turn changed its name, becoming known as Oracle Corporation to align itself more closely with its flagship product. The company released Oracle version 3, which it had re-written using the C programming language and which supported COMMIT and ROLLBACK functionality for transactions. Version 3 extended platform support from the existing Digital VAX/VMS systems to include Unix environments. Ну наконец, то. Прошло 6 лет. Появились транзакции
In 1984 Oracle Corporation released Oracle version 4, which supported read-consistency. Прошло 7 лет, облом. До этого это были не транзакции. Через семь лет — это можно назвать базой данных.
Starting 1985, the Oracle DBMS began supporting the client-server model, with networks becoming available in the mid-1980s. Oracle version 5.0 supported distributed queries. Из другого источника — By 1985, Oracle could claim more than 1,000 relational database customer sites. Действительно много. Только на фоне общего количества баз данных, цифра не впечатляет.
In 1988 Oracle Corporation entered the application products market and developed its ERP product — Oracle Financials based on the Oracle relational database. Oracle RDBMS version 6 came out with support for PL/SQL, row-level locking and hot backups. Oh PL/SQL — that's good
In 1992 Oracle version 7 appeared with support for integrity constraints, stored procedures and triggers.
Ну вот, теперь мы можем считать Oracle полноценной реляционной базой данных современного уровня и определения Кодда. Ключевое достижение не триггеры а выделенное. Прошло 15 лет с дня основания.
Для справки. 12 правил Кодда для опрделения является ли база данных реляционной.
Rule 0: The system must qualify as relational, as a database, and as a management system.
For a system to qualify as a relational database management system (RDBMS), that system must use its relational facilities (exclusively) to manage the database.
Rule 1: The information rule:
All information in the database to be represented in one and only one way, namely by values in column positions within rows of tables.
Rule 2 : The guaranteed access rule:
All data must be accessible with no ambiguity. This rule is essentially a restatement of the fundamental requirement for primary keys. It says that every individual scalar value in the database must be logically addressable by specifying the name of the containing table, the name of the containing column and the primary key value of the containing row.
Rule 3: Systematic treatment of null values:
The DBMS must allow each field to remain null (or empty). Specifically, it must support a representation of "missing information and inapplicable information" that is systematic, distinct from all regular values (for example, "distinct from zero or any other number," in the case of numeric values), and independent of data type. It is also implied that such representations must be manipulated by the DBMS in a systematic way.
Rule 4: Active online catalog based on the relational model:
The system must support an online, inline, relational catalog that is accessible to authorized users by means of their regular query language. That is, users must be able to access the database's structure (catalog) using the same query language that they use to access the database's data.
Rule 5: The comprehensive data sublanguage rule:
The system must support at least one relational language that
(a) Has a linear syntax
(b) Can be used both interactively and within application programs,
(c) Supports data definition operations (including view definitions), data manipulation operations (update as well as retrieval), security and integrity constraints, and transaction management operations (begin, commit, and rollback).
Rule 6: The view updating rule:
All views that are theoretically updatable must be updatable by the system.
Rule 7: High-level insert, update, and delete:
The system must support set-at-a-time insert, update, and delete operators.
Rule 8: Physical data independence:
Changes to the physical level (how the data is stored, whether in arrays or linked lists etc.) must not require a change to an application based on the structure.
Rule 9: Logical data independence:
Changes to the logical level (tables, columns, rows, and so on) must not require a change to an application based on the structure. Logical data independence is more difficult to achieve than physical data independence.
Rule 10: Integrity independence:
Integrity constraints must be specified separately from application programs and stored in the catalog. It must be possible to change such constraints as and when appropriate without unnecessarily affecting existing applications.
Rule 11: Distribution independence:
The distribution of portions of the database to various locations should be invisible to users of the database. Existing applications should continue to operate successfully :
(a) when a distributed version of the DBMS is first introduced; and
(b) when existing distributed data are redistributed around the system.
Rule 12: The nonsubversion rule:
If the system provides a low-level (record-at-a-time) interface, then that interface cannot be used to subvert the system, for example, bypassing a relational security or integrity constraint.
M>>>Это их личные проблемы. Чисто математически теория графов будет по старше реляционной, однако не XML, не OODB это не помогло, видать не спроста.... GZ>>А причем тут теория графов? M>При том, что и XML и OODB и прочие иерархические конструкции основаны на теории графов.
Нет, теория множеств. Как и реляционка.
GZ>>Статью в которой они опубликовали BNF сиквела(о чем потом сожалели разработчики)? M>Да кому сдался BNF? BNF это исключительно синтаксис, по одному BNF-у ты систему не построишь. Это была чисто маркетинговая промашка, но ни как она не помогла Ораклоидам в плане реализации, у них к томц времени свой язык был, очень не плохо работающий. GZ>>Oracle изначально делался во время System/R и использовал результаты SystemR. M>Оракл стал выполнять гос-заказы, когла System R был еще в глубокой теории, и что-то мне не верится в безмерную щедрость IBM раздававшую нахаляву подробности своей закрытой системы. К слову, про внутренности оптимизатров до сих пор мало что толком известно широкой общественности. Так что Оракл был проект вполне себе независимый.
Список работ опубликованный разработчиками System/R.
ADIB 80
Michel E. Adiba, Bruce G. Lindsay. "Database Snapshots" Proceedings of VLDB 1980, p. 86-91.
ASTR 75a
M. M. Astrahan and D. D. Chamberlin. "Implementation of a Structured English Query Language" Communications of the ACM, Vol. 18, No. 10, October 1975.
ASTR 75b
M. M. Astrahan and R. A. Lorie. "SEQUEL-XRM: A Relational System" Proceedings of ACM Pacific Regional Conference, San Francisco, CA., April 1975, p. 34.
ASTR 76
M. M. Astrahan, M. W. Blasgen, D. D. Chamberlin, K. P. Eswaran, J. N. Gray, P. P. Griffiths, W. F. King, R. A. Lorie, P. R. McJones, J. W. Mehl, G. R. Putzolu, I. L. Traiger, B. Wade, and V. Watson. "System R: A Relational Approach to Database Management" ACM Transactions on Database Systems, June 1976, p. 97. online
ASTR 79
M. M. Astrahan, M. W. Blasgen, D. D. Chamberlin, J. N. Gray, W. F. King, B. G. Lindsay, R. A. Lorie, J. W. Mehl, T. G. Price, G. R. Putzolu, M. Schkolnick, P. P. Selinger, D. R. Slutz, H. R. Strong, P. Tiberio, I. L. Traiger, B. W. Wade, and R. A. Yost. "System R: A Relational Data Base Management System" IEEE Computer, May 1979, p. 43.
ASTR 80a
M. M. Astrahan, W. Kim, and M. Schkolnick. "Performance of the System R Access Path Selection Mechanism" Proceedings of the IFIP Congress, Melbourne, Australia, 1980.
BLAS 77a
M. W. Blasgen and K. P. Eswaran. "Storage and Access in Relational Databases" IBM Systems Journal, No. 4, 1977, p. 363.
BLAS 77b
M. W. Blasgen, R. G. Casey, and K. P. Eswaran. "An Encoding Method for Multifield Sorting and Indexing" Communications of the ACM, Nov. 1977, p. 874.
BLAS 79
M. Blasgen, J. Gray, M. Mitoma, and T. Price. "The Convoy Phenomenon" ACM Operating Systems Review, Vol. 13, No. 2, April 1979, p. 20.
BLAS 81
M. W. Blasgen, M. M. Astrahan, D. D. Chamberlin, J. N. Gray, W. F. King, B. G. Lindsay, R. A. Lorie, J. W. Mehl, T. G. Price, G. R. Putzolu, M. Schkolnick, P. G. Selinger, D. R. Slutz, H. R. Strong, I. L. Traiger, B. W. Wade, and R. A. Yost. "System R: An Architectural Overview" IBM Systems Journal, Vol. 20, No. 1, Feb. 1981, p. 41.
BOYCE 73
R. F. Boyce and D. D. Chamberlin. "Using a Structured English Query Language as a Data Definition Facility" IBM Research Report RJ1318, San Jose, CA., December 1973.
BOYCE 75
R. F. Boyce, D. D. Chamberlin, W. F. King, and M. M Hammer. "Specifying Queries as Relational Expressions: the SQUARE Data Sublanguage" Communications of the ACM, November 1975, p. 621.
CHAM 74
D. D. Chamberlin and R. F. Boyce. "SEQUEL: A Structured English Query Language" Proceedings of the ACM-SIGMOD Workshop on Data Description, Access, and Control, May 1974.
CHAM 75
D. D. Chamberlin, J. N. Gray, and I. L. Traiger. "Views, Authorization, and Locking in a Relational Database System" Proceedings of the 1975 National Computer Conference, p. 425.
CHAM 76a
D. D. Chamberlin, M. M. Astrahan, K. P. Eswaran, P. P. Griffiths, R. A. Lorie, J. W. Mehl, P. Reisner, and B. W. Wade. "SEQUEL 2: A Unified Approach to Data Definition, Manipulation, and Control" IBM Journal of Research and Development, Nov. 1976, p.560. (Also see errata in January 1977 issue.)
CHAM 76b
D. D. Chamberlin. "Relational Database Management Systems" Computing Surveys, March 1976, p. 43.
CHAM 78
D. D. Chamberlin, J. N. Gray, P. P. Griffiths, M. Mresse, I. L. Traiger, and B. W. Wade. "Data Base System Authorization" in Foundations of Secure Computation (edited by R. Demillo, D. Dobkin, A. Jones, and R. Lipton), Academic Press, 1978, p. 39.
CHAM 80
D. D. Chamberlin. "A Summary of User Experience with the SQL Data Sublanguage" Proceedings of the International Conference on Data Bases, Aberdeen, Scotland, July 1980. Also IBM Research Report RJ2767, San Jose, CA., April 1980.
CHAM 81a
D. D. Chamberlin, M. M. Astrahan, W. F. King, R. A. Lorie, J. W. Mehl, T. G. Price, M. Schkolnick, P. G. Selinger, D. R. Slutz, B. W. Wade, and R. A. Yost. "Support for Repetitive Transactions and Ad-Hoc Queries in System R" ACM Transactions on Database Systems, Vol. 6, No. 1, March 1981, p. 70.
CHAM 81b
D. D. Chamberlin, A. M. Gilbert, and R. A. Yost. "A History of System R and SQL/Data System". Proceedings of the International Conference on Very Large Data Bases, Cannes, France, September 1981, pp. 456-464.
CHAM 81c
D. D. Chamberlin, M. M. Astrahan, M. W. Blasgen, J. N. Gray, W. F. King, B. G. Lindsay, R. Lorie, J. W. Mehl, T. G. Price, F. Putzolu, P. G. Selinger, M. Schkolnick, D. R. Slutz, I. L. Traiger, B. W. Wade, and R. A. Yost. "A History and Evaluation of System R" Communications of the ACM, Vol. 24, No. 10, October 1981, pp. 632-646.
CODD 81
E. F. Codd. "The Significance of the SQL/Data System Announcement" Computerworld, Feb. 16, 1981.
ESWA 75
K. P. Eswaran and D. D. Chamberlin. "Functional Specifications of a Subsystem for Database Integrity" Proceedings of the Conference on Very Large Data Bases, Framingham, Mass., Sept. 1975.
ESWA 76
K. P. Eswaran, J. N. Gray, R. A. Lorie, and I. L. Traiger. "On the Notions of Consistency and Predicate Locks in a Database System" Communications of the ACM, November 1976, p. 624.
FAGIN 78
R. Fagin. "On an Authorization Mechanism" ACM Transactions on Database Systems, September 1978, p. 310.
GRAY 75a
J. N. Gray and V. Watson. "A Shared Segment and Inter-process Communication Facility for VM/370." IBM Research Report RJ1579, San Jose, CA., Feb. 1975.
GRAY 75b
J. N. Gray, R. A. Lorie, and G. F. Putzolu. "Granularity of Locks in a Large Shared Database" Proceedings of the Conference on Very Large Data Bases, Framingham, Mass., September 1975.
GRAY 76
J. N. Gray, R. A. Lorie, G. R. Putzolu, and I. L. Traiger. "Granularity of Locks and Degrees of Consistency in a Shared Data Base" Proceedings of the IFIP Working Conference on Modelling of Database Management Systems, Freudenstadt, Germany; January 1976; p. 695. (Also appeared as IBM Research Report RJ1654, San Jose, CA.)
GRAY 78
J. N. Gray. "Notes on Database Operating Systems" in Operating Systems: An Advanced Course (edited by Goos and Hartmanis), Springer-Verlag, 1978, p. 393. Also IBM Research Report RJ2188, San Jose, CA.
GRAY 79
J. N. Gray, P. McJones, M. W. Blasgen, R. A. Lorie, T. G. Price, G. R. Putzolu, and I. L. Traiger. "The Recovery Manager of a Data Management System" ACM Computing Surveys, Vol. 13, No. 2, June 1981, pp. 223-242.
GRIF 76
P. P. Griffiths and B. W. Wade. "An Authorization Mechanism for a Relational Database System" ACM Transactions on Database Systems, September 1976, p. 242.
IBM 81a
SQL/Data System, General Information Manual. Publication No. GH24-5012, IBM Corp., White Plains, NY, 1981.
IBM 81b
SQL/Data System, Concepts and Facilities. Publication No. GH24-5013, IBM Corp., White Plains, NY, 1981.
IBM 81c
SQL/Data System for VSE: A Relational Data System for Application Development. Publication No. G320-6590, IBM Corp., White Plains, NY, 1981.
KWAN 80
S. C. Kwan and H. R. Strong. "Index Path Length Evaluation for the Research Storage System of System R" IBM Research Report RJ2736, San Jose, CA., January 1980.
LORIE 74
R. A. Lorie. "XRM — An Extended (N-ary) Relational Memory" IBM Technical Report G320-2096, Cambridge Scientific Center, Cambridge, MA., January 1974.
LORIE 77
R. A. Lorie. "Physical Integrity in a Large Segmented Database" ACM Transactions on Database Systems, March 1977, p. 91.
LORIE 79a
R. A. Lorie and B. W. Wade. "The Compilation of a High Level Data Language" IBM Research Report RJ2598, San Jose, CA., August 1979.
LORIE 79b
R. A. Lorie and J. F. Nilsson. "An Access Specification Language for a Relational Data Base System" IBM Journal of Research and Development, May 1979, p. 286.
REIS 75
P. Reisner, R. F. Boyce, and D. D. Chamberlin. "Human Factors Evaluation of Two Data Base Query Languages--SQUARE and SEQUEL" Proceedings of the AFIPS National Computer Conference, Anaheim, CA, May 1975, p. 447.
REIS 77
P. Reisner. "Use of Psychological Experimentation as an Aid to Development of a Query Language" IEEE Transactions on Software Engineering, Vol. SE-3, May 1977, p. 218.
SCHK 79
M. Schkolnick and P. Tiberio. "Considerations in Developing a Design Tool for a Relational DBMS" Proc. IEEE COMPSAC '79, November 1979.
SELI 79
P. G. Selinger, M. M. Astrahan, D. D. Chamberlin, R. A. Lorie, and T. G. Price. "Access Path Selection in a Relational Database Management System" Proceedings of the ACM SIGMOD Conference, June 1979.
STRO 78
H. R. Strong, I. L. Traiger, and G. Markowsky. "Slide Search" IBM Research Report RJ2274, San Jose, CA., June 1978.
TRAI 79
I. L. Traiger, J. N. Gray, C. A. Galtieri, and B. G. Lindsay. "Transactions and Consistency in Distributed Database Systems" IBM Research Report RJ2555, San Jose, CA., June 1979.
GZ>>Из законченных решений мне я видел работы Fegaras и Cherniack and Zdonik. Наверняка есть еще что-то. M>И что толку от этих работ? Где реально работающие системы?
Спроси у версантовцев.
GZ>> Таблица всего лишь структура которая не обязательно принадлежит реляционной модели. Подробности у Дейта. M>Если таблицей называть структуру, которая удовлетворяет 1НФ, и над которой определены операции реляционной алгебры, то она таки принадлежит реляционной модели. Подробности можешь смотреть у кого угодно, от Бойса с Коддом и Греем, до Дейта с Бернстайном и Уидомом.
Правильно. Если определены. Если довести до маразма, то можно сказать и так int i=10; является реляционной структурой поскольку находится в 1НФ, а можно сразу сказать в 10. И над ним можно определить реляционные операции.
GZ>>Нет. Не любыми. Можешь привести цифры какие накладные расходы происходят при хранении xml в реляционной модели в SQL2005 и почему они все таки хранят xml в CLOB? M>Кто тебе сказал, что они хранят это дело в CLOB? здесь
Здравствуйте, GlebZ, Вы писали:
GZ>OK — экскурс
Делать нечего?
GZ>[q] GZ>Larry Ellison founded Software Development Laboratories in 1977. In 1979 SDL changed its company-name to Relational Software, Inc. (RSI) and introduced its product Oracle V2 as an early commercially-available relational database system.
Заметь, с начала проекта прошло ровно два года. И к моменту комммерциализации она уже имела в своем активе серьезные гос заказы.
GZ>Да уж. Такое базой данных назвать трудно.
А ты задумайся, кто на тот момент вообще поддерживал транзакции. Не оценивай тот Оракл по современным меркам, он был на уровне тех БД.
GZ>Прошло 7 лет, облом. До этого это были не транзакции. Через семь лет — это можно назвать базой данных.
Не облом, это они версионность приделали, до этого как и айбиэмеры они блокировочник писали, вполне себе с транзакциями и Concurrency Control.
GZ>Из другого источника — By 1985, Oracle could claim more than 1,000 relational database customer sites. Действительно много. Только на фоне общего количества баз данных, цифра не впечатляет.
На уровне общего количества в то время? Это очень и очень впечатляет.
GZ>In 1992 Oracle version 7 appeared with support for integrity constraints, stored procedures and triggers. GZ>Ну вот, теперь мы можем считать Oracle полноценной реляционной базой данных современного уровня
Она всегда была современного уровня, просто современный уровень рос и Oracle вместе с ним.
GZ>и определения Кодда. GZ>Для справки. 12 правил Кодда для опрделения является ли база данных реляционной. Для справки. Определениям Кодда не соответствует ни одна современная РСУБД.
GZ>Список работ опубликованный разработчиками System/R.
Это список работ по реляционной теории, а не по реализации РСУБД. Работ по теории XML и OODB в сотни раз больше, а результат близок к нулю.
GZ>Спроси у версантовцев.
А чего у них спрашивать, не смотря на изнурительные попытки протолкнуть свою ООБД, деньги они зарабатывают на ORM-е, помоему вполне симптоматично.
GZ>Правильно. Если определены. Если довести до маразма, то можно сказать и так int i=10;
Давай до маразма не доводить. Итого, если у нас есть отношение над которым определены реляционные опреации, то мы имеем дело с реляционкой.
M>>Кто тебе сказал, что они хранят это дело в CLOB? GZ>здесь
Ты не правильно прочитал.. Это личное мнение автора, что XML удобнее всего хранить в CLOB-е, про 2005й там ни слова...
GZ>А че, словами уже сложно?
А что словами? словами я ого-го как могу, особенно на общие темы и безовсякой конкретики, вон топик уже за сотню сообщений перевалил...
Не мешки же, в конце-концов.
Здравствуйте, Merle, Вы писали:
GZ>>Список работ опубликованный разработчиками System/R. M>Это список работ по реляционной теории, а не по реализации РСУБД. Работ по теории XML и OODB в сотни раз больше, а результат близок к нулю.
Извините, что вмешиваюсь в ваш междусобойчик, но по поводу OODB хотелось бы пару слов вставить:
-- в отличии от реляционной модели ООП слишком аморфное понятие, как показывают здешние дискуссии, каждый волен понимать под ООП и ОО моделью что-то свое;
-- реляционная модель не завязана на конкретный язык программирования. А вот ОО модель в каждом языке своя. В C++, скажем, нет понятия интерфейсов, множественное наследование всегда от классов. В C#/Java есть понятие интерфейсов, между которыми есть свои отношения наследования, но, как говорят, реализация множества интерфейсов классом не есть наследование от интерфейса (а собственно наследование всегда только одиночное). Попытка создать ОО модель данных, которую можно будет отобразить одновременно в C++ программу, Java программу или Ruby программу приведет к такому куцему варианту, что преимуществ от объектности данных в каждой из программ можно вообще не получить. Поэтому ООБД часто ориентированы только на один ОО язык и только не многие ООБД поддерживают несколько близких языков. В то время, как поддержка РСУБД есть практически в любом более-менее успешном языке программирования и/или его стандартной библиотеке;
-- ООБД гораздо менее известны и не преподаются (либо преподаются очень редко). Поэтому далеко не все разработчики могут себе представить, когда ООБД будет эффективнее РСУБД. Соответственно, на ООБД меньше спрос, а чем меньше спрос, тем меньше и предложение.
Все эти факторы отрицательно влияют на популярность и распространенность ООБД. Да еще при том, что для 90% (disclamer: цифра с потолка) задач существующие РСУБД прекрасно справляются.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Merle, Вы писали:
M>Здравствуйте, GlebZ, Вы писали:
GZ>>OK — экскурс M>Делать нечего?
Ага. У меня сегодня день рождения моего кровопийцы. Два года. Поэтому воинственно радуюсь жизни.
GZ>>
GZ>>Larry Ellison founded Software Development Laboratories in 1977. In 1979 SDL changed its company-name to Relational Software, Inc. (RSI) and introduced its product Oracle V2 as an early commercially-available relational database system.
M>Заметь, с начала проекта прошло ровно два года. И к моменту комммерциализации она уже имела в своем активе серьезные гос заказы.
Заказы уже были на момент основания. Насколько я помню, она была и основана благодаря тому что Эллисон выбил деньги из военных.
GZ>>Да уж. Такое базой данных назвать трудно.
M>А ты задумайся, кто на тот момент вообще поддерживал транзакции. Не оценивай тот Оракл по современным меркам, он был на уровне тех БД.
[q]
Standard transaction processing middleware, notably IBM's Information Management System, emerged in the 1960s and was often closely coupled to particular database management systems.
GZ>>Прошло 7 лет, облом. До этого это были не транзакции. Через семь лет — это можно назвать базой данных. M>Не облом, это они версионность приделали, до этого как и айбиэмеры они блокировочник писали, вполне себе с транзакциями и Concurrency Control.
Maybe. Не подумал.
GZ>>Из другого источника — By 1985, Oracle could claim more than 1,000 relational database customer sites. Действительно много. Только на фоне общего количества баз данных, цифра не впечатляет. M>На уровне общего количества в то время? Это очень и очень впечатляет.
Да нет. Клиент-серверные системы только начинали свое существование. Поэтому 1000 даже для того времени была небольшая цифра.
GZ>>In 1992 Oracle version 7 appeared with support for integrity constraints, stored procedures and triggers. GZ>>Ну вот, теперь мы можем считать Oracle полноценной реляционной базой данных современного уровня M>Она всегда была современного уровня, просто современный уровень рос и Oracle вместе с ним.
GZ>>и определения Кодда. GZ>>Для справки. 12 правил Кодда для опрделения является ли база данных реляционной. M> Для справки. Определениям Кодда не соответствует ни одна современная РСУБД.
Я читал почему не соответствуют. Не впечатлило.
GZ>>Список работ опубликованный разработчиками System/R. M>Это список работ по реляционной теории, а не по реализации РСУБД.
Нет. Это как раз о реализации. Реализация СУБД — значительно больше чем одна теория. Это и транзакции, и способы нахождения оптимального плана. и т.д. и т.п. M>Работ по теории XML и OODB в сотни раз больше, а результат близок к нулю.
Повторяю. Результаты то есть. Но для большинства хватает реляционки. О чем и разговор.
GZ>>Спроси у версантовцев. M>А чего у них спрашивать, не смотря на изнурительные попытки протолкнуть свою ООБД, деньги они зарабатывают на ORM-е, помоему вполне симптоматично.
То что ORM продать легче чем OODB? Не сомневался.
M>>>Кто тебе сказал, что они хранят это дело в CLOB? GZ>>здесь
M>Ты не правильно прочитал.. Это личное мнение автора, что XML удобнее всего хранить в CLOB-е, про 2005й там ни слова...
А здесь здесь
SQL Server 2005 introduces a native data type called XML. A user can create a table with one or more columns of type XML besides relational columns; XML variables and parameters are also allowed. XML values are stored in an internal format as large binary objects (BLOB) in order to support the XML model characteristics more faithfully such as document order and recursive structures.
GZ>>А че, словами уже сложно? M>А что словами? словами я ого-го как могу, особенно на общие темы и безовсякой конкретики, вон топик уже за сотню сообщений перевалил... M>Не мешки же, в конце-концов.
Отмазки? Ну валяй источниками. Интересно.
Здравствуйте, Cyberax, Вы писали:
C>Эээ... Вообще-то, "relation" переводится как "отношение, связь". Способ C>эффективно представить дерево в РБД — я уже привел.
Эээ. Связь может быть между таблицами, а может быть между строками. В данном случае имеется ввиду именно связь кортежей в отношении.
). Для xml есть некоторая xpath команда в виде //bla-bla. То есть получить все бла-бла независимо от местоположения. То есть путь к этим объектам мы не знаем, и он может быть любым. И существует достаточно много таких комманд подразумевающих, что местоположение объекта не определено. В случае реляционки любая команда SQL подразумевает о том, что она знает где находятся данные. И свести к реляционке подобную модель и далее оперировать стандартными реляционными операциями не всегда представляется возможным. 
Если нам не помогут, то мы тоже никого не пощадим.
Мы уже победили, просто это еще не так заметно...
В 74 году(через пять лет после выпуска статьи Кодда) реляционки были только на бумаге. А XML базы уже существуют.
Поэтому воинственно радуюсь жизни.
