Возможно, вопрос поставлен слишком жестко, но все же.
Я думаю, многие меня поддержат. Реляционные базы данных — это большой геморрой. Возможно, ничего лучшего не придумано (?), но геморроем они от этого быть не перестают.
Два раза мне приходилось работать над проектами (и оба раза — неудачными ), где велась работа с разнообразными, но _родственными_ объектами. Или объектами, различающимися в одном свойстве, но от этого свойства изменялась логика работы приложения.
Пример
Имеем туристическую компанию, резервирующую места в отелях. Казалось бы, что может быть проще?
Резервации могут быть поименно/пономерно. Могут быть списком в n человек на заранее зарегистрированные номера. могут быть блоком (20 SNGL, 10 DBL, 5 TRPL) комнат на будущее.
Могут быть с полным питанием (Full Board, BB), могут быть с половинным (HB).
Могут быть с детьми (у разных отелей — разная политика на детей, например 0-6 бесплатно, 6-12 50% скидка или 0-4 бесплатно, 4-8 50%, 8-12 25%)
Могут попадать на межсезонье в отеле (половина — по одной цене, вторая половина — по другой, завышенной, а что делать — например Формула 1 проходит)
Представляете, да? При этом оператор должен видеть все эти резервации в списке, делать по ним выборку произвольным образом (а покажите-ка мне блочные резервации в отель Zurich с 15-го сентября сего года).
Что самое интересное, в таком случае проблема не в обработке данных — что их там обрабатывать? Проблема — в самих данных. Что как и куда хранить? Проектировка базы — кошмар. Нормализация базы — еще тот геморрой. Расширение понятия "резервация"? Практически нереально (дополнительные таблицы, колонки, ключи...) Я конечно не спорю, многое зависит от кривых шаловливых ручек разработчика, но, имхо, рано или поздно приходишь к выводу, что пытаешься "впихнуть невпихуемое".
Альтернативы в студию. Есть такая штука как Cache, говорят хорошая вещь. Но сам не работал, поэтому ничего не скажу ни плохого, ни хорошего. Думается, компетентно на ваш вопрос ответят те, кто пользовал иной, нежели реляционный, подход.
Приходиться заниматься гадостью — зарабатывать на жизнь честным трудом (Б.Шоу)
Здравствуйте, Mamut, Вы писали:
M>Возможно, вопрос поставлен слишком жестко, но все же.
M>Я думаю, многие меня поддержат. Реляционные базы данных — это большой геморрой. Возможно, ничего лучшего не придумано (?), но геморроем они от этого быть не перестают.
Не поддержу Лично я не считаю это геморроем, тем более что особо выбирать-то и не из чего
...skipped...
M>Может, ну ее, эту реляцию, к чертям? Ы?
Критикуешь — предлагай Итак, прежде чем послать к чертям реляционную модель данных, хотелось бы услышать про что-то, что по твоему мнению позволило бы решить твою задачу легко и непринужденно. Возможно, сейчас разгорится спор насчет ООСУБД, их применимости в реальном мире, и т.д.
А еще более обще — а как ты себе видишь _идеальную_ реализацию твоей задачи? На любом гипотетическом языке Х, который позволит сделать все легко и прозрачно... В чем счастье, брат? (с)
ЗЫ: Лично я не вижу ничего кошмарного в данной задаче... В свое время приходилось работать примерно с такой же задачей, все было ок...
Это что, а вот с использованием XML-я обеспечить элементарную ссылочную целостность — это такой геморрой...
Да и эффективно программировать на нем драйвера могут только окончательно продвинувшиеся
Так что XML — тоже в топку?
Здравствуйте, Mamut, Вы писали:
M>Возможно, вопрос поставлен слишком жестко, но все же.
M>Я думаю, многие меня поддержат. Реляционные базы данных — это большой геморрой. Возможно, ничего лучшего не придумано (?), но геморроем они от этого быть не перестают.
M>Два раза мне приходилось работать над проектами (и оба раза — неудачными ), где велась работа с разнообразными, но _родственными_ объектами. Или объектами, различающимися в одном свойстве, но от этого свойства изменялась логика работы приложения. ...
См. "Архитектура корпоративных приложений" М. Фаулера.
Банальности, тезисно.
1. Основной недостаток реляционных баз данных — в реляциях Точнее — в том, что отношения между данным размываются на 2 "слоя" — в коде и в базе.
2. Основное преимущество реляционных баз данных — функциональный SQL; лучше которого для запроса к данным еще не придумано. Его вон даже MS в C# 3.0 имитирует
Здравствуйте, mrozov, Вы писали:
M>Это что, а вот с использованием XML-я обеспечить элементарную ссылочную целостность — это такой геморрой... M>Да и эффективно программировать на нем драйвера могут только окончательно продвинувшиеся M>Так что XML — тоже в топку?
XML-то? Да в первую очередь!!!
Просто пошутил. Такая флеймовая тема, что позволил себе приколоться.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ЗХ>>ЗЫ: в текущем проекте у меня база с единственной таблицей [objId, propertyName, propertyValue]
ANS>А propertyValue это строка?
В общем-то да, но база SQLite, у нее значения "почти нетипизированные" — insert ...values(1) — записал int, insert ...values(1.0) — float, insert ... values("1") — строку
M>>Может, ну ее, эту реляцию, к чертям? Ы?
DD>Критикуешь — предлагай Итак, прежде чем послать к чертям реляционную модель данных, хотелось бы услышать про что-то, что по твоему мнению позволило бы решить твою задачу легко и непринужденно. Возможно, сейчас разгорится спор насчет ООСУБД, их применимости в реальном мире, и т.д.
Because we have about 2 gigs of static data we need rapid access to, we use C++ code to memory-map huge files containing pointerless C structs (of flights, fares, etc), and then access these from Common Lisp
They chose AllegroStore because an Object Oriented Database was needed to more precisely measure and manage the many complex factors within the constantly evolving database. "We could have used a relational database," says Kawai, "but the workflow would have been very different. By using AllegroStore, we were able to accommodate any production requests that came through. We couldn't have done that with a relational database."
DD>А еще более обще — а как ты себе видишь _идеальную_ реализацию твоей задачи? На любом гипотетическом языке Х, который позволит сделать все легко и прозрачно... В чем счастье, брат? (с)
DD>ЗЫ: Лично я не вижу ничего кошмарного в данной задаче... В свое время приходилось работать примерно с такой же задачей, все было ок...
Вообще, чего мне вдруг стукнуло в голову — просто связь логики приложения и данных приложения, как таковая, отсутствует. А хоцца, чтоб не отсутствовала
F>Альтернативы в студию. Есть такая штука как Cache, говорят хорошая вещь. Но сам не работал, поэтому ничего не скажу ни плохого, ни хорошего. Думается, компетентно на ваш вопрос ответят те, кто пользовал иной, нежели реляционный, подход.
Здравствуйте, Mamut, Вы писали:
M>>>Может, ну ее, эту реляцию, к чертям? Ы?
DD>>Критикуешь — предлагай Итак, прежде чем послать к чертям реляционную модель данных, хотелось бы услышать про что-то, что по твоему мнению позволило бы решить твою задачу легко и непринужденно. Возможно, сейчас разгорится спор насчет ООСУБД, их применимости в реальном мире, и т.д.
M>Ну, скажем, Orbitz: M>
M>Because we have about 2 gigs of static data we need rapid access to, we use C++ code to memory-map huge files containing pointerless C structs (of flights, fares, etc), and then access these from Common Lisp
Не, это шаг назад, когда приложение заботится о инфраструктуре хранения своих данных.
M>Ну или Square USA: M>
M>They chose AllegroStore because an Object Oriented Database was needed to more precisely measure and manage the many complex factors within the constantly evolving database. "We could have used a relational database," says Kawai, "but the workflow would have been very different. By using AllegroStore, we were able to accommodate any production requests that came through. We couldn't have done that with a relational database."
ООСУБД, как вариант, согласен...
DD>>А еще более обще — а как ты себе видишь _идеальную_ реализацию твоей задачи? На любом гипотетическом языке Х, который позволит сделать все легко и прозрачно... В чем счастье, брат? (с)
DD>>ЗЫ: Лично я не вижу ничего кошмарного в данной задаче... В свое время приходилось работать примерно с такой же задачей, все было ок...
M>Вообще, чего мне вдруг стукнуло в голову — просто связь логики приложения и данных приложения, как таковая, отсутствует. А хоцца, чтоб не отсутствовала
ORM? с прозрачным persistance для объектов? Чем не вариант? Хотя получаем лишнюю прослойку... Конечно, если БД поддерживает такие операции напрямую, это гораздо интереснее... В этом смысле действительно будет интересно поразбираться с Cache'. Хотя опыт подсказывает, что и тут должны быть какие-то недостатки...
Здравствуйте, Зверёк Харьковский, Вы писали:
ЗХ>>>ЗЫ: в текущем проекте у меня база с единственной таблицей [objId, propertyName, propertyValue]
ANS>>А propertyValue это строка?
ЗХ>В общем-то да, но база SQLite, у нее значения "почти нетипизированные" — insert ...values(1) — записал int, insert ...values(1.0) — float, insert ... values("1") — строку
Ясно. Меня этот подход смущяет именно ограниченной типизируемостью в случае "старших братьев".
Что касается слухов смерти реляционных БД, то они несколько преувеличены. Да действительно недостатком реляционки — является их реляционность. В то же время достоинство реляционных БД — их реляционность. Законы теории ООП не совсем похожи на законы теории данных. Реляционная модель — это сеть с помощью которой можно отобразить любую предметную область. Реляционная модель хорошо адаптируется под любую структуру сохраняя оптимальность хранения. В действительности, то что ты данные можешь положить в отношения так как тебе угодно — большой плюс. Благодаря этому физическая модель при которой работа с данными наиболее эффективна, легко трансформируется в логическую модель которую можно представить на уровень клиента. Недостаток, тот же. Модель предоставляемая клиенту должна быть также реляционной. Из-за этого бывает достаточно много геммороя. Только он как успешно решался, так успешно и решается. Лучше конечно без него, но нет ничего слишком криминального в этом, чтобы говорить о конце света.
Здравствуйте, Mamut, Вы писали:
M>Я думаю, многие меня поддержат. Реляционные базы данных — это большой геморрой.
Это реляционные базы геморрой? Реляционные СУБД позволяют быстро и эффективно решать прорву вопросов.
Для интересующихся привожу фрагмент своего давнего письма товарищам на тему сетевых БД, возникшего в результате спора, "а кто же круче".
Сорри за присутствующий несколько шутливый тон и возможные неточности, это был момент с оттенком истерии ))
//------------------ letter
"..когда мужчины были настоящими мужчинами
и сами писали драйвера устройств."
Линус Торвальдс
О сетевых БД
Господа офицеры! Познакомился я в последнее время с чудесной СУБД dbVista (с) Raima Corp.
Очень старый продукт, но, что интересно, до сих пор существуют энтузиасты которые его продвигают как open-source проект.
Как человек, использовавший в разное время в разной степени Oracle, MySQL и FireBird,
испытал просто высочайшее интеллектуальное наслаждение при работе с этой сетевой СУБД,
коим и поделюсь с уважаемым мною all ниже.
Прежде всего, гордый маленький дескрипшн из официальной документации:
"Сетевая модель позволяет избежать избыточности благодаря тому,
что связывание двух типов записи происходит напрямую,
без обязательного дублирования полей и индекснов.
Кроме того, переход от одной связанной записи к другой
осуществляется за одну операцию чтения, а вот реляционная модель
вынуждает Вас делать лишний запрос для выбора ключа связанной записи."
Краткое описание процесса использования Vista.
Итак, программист, одержимый поисками силы, делает следующее:
1) описывает структуру БД с использованием DDL (есс-но Database Definition Language гы);
2) компилит ее компилятором ddlp и создает с помощью спецтулзы initdb свою БД.
БД представляет собой:
— бинарники: набор файлов данных, словарей, ключевых файлов;
— С-хидер! Сгенерирован для доступа к нашей БД. Подключаем его к проекту,
ибо в нем описаны все наши константы и записи в виде define'ов и struct'ов;
3) Пишет всяческий код для доступа к данным пользуя вистовский АПИ;
4) Goto 1.
Теперь замечания по пунктам:
1.1) Данные ораганизовываются через records и sets.
Record описывает запись/тип с его fields, types, keys, и проч;
а в set'ах определяются связи между records. 1 set задает связь вида 1:n.
1 Owner — N members. Супер.
В set указывается также order — т.е. явно в схеме БД указываем куда vista будет
добавлять member'ы в set — в начало их будет ложить или, может, в конец очереди.
1.2) Интересная ситуация с индексами/ключами. Что меня особенно удивило, они есть.
Но:
— программист сам управляет в каких файлах каким индексам надлежит хранится.
Забегая вперед — "подводных граблей" (с) здесь водится
неимоверное количество, ибо файлы с ключами
блокируются при многопользовательской работе целиком.
Т.е. если в файле n индексов, то все n и блокируются;
— использование... вот здесь вы точно удивитесь см пункт 3.1
3.1) Про организацию доступа... отдельный протяжный стон
3.1.1) Значит так, создатели dbVista предоставляют мощный API для работы с БД — пару-тройку десятков функций с названием вида d_<кммбвнр>, где <кммбвнр> означает как_можно_меньше_букв_в_нижнем_регистре, например — d_keyfrst или d_setor.
3.1.2) На все record'ы существует одна текущая запись.
Для каждого set существует один текущий member и текущий owner.
Текущим состоянием программист манипулирует с помощью функций.
ПРИМЕР:
1) Есть БД:
record Main
{
unique key int iMainKey;
}
record Child
{
unique key int iChildKey;
}
set SuperSet
{
order last;
owner Main;
member Child;
}
2) Создадим, например, Childa и прилинкуем его к Main'у с номером 5
/* ищем в MAIN запись с iMainKey=5.
Если Vista чего-то найдет - сделает запись текущей
и с ней смогут работать другие функции
*/
d_keyfind(IMAINKEY, (char *) 5); /* type safety на высоте ))*/
/* проверка ошибок */if (db_status!=S_OKAY) return NO_SUCH_ENTRY;
/* делаем текущую запись владельцем setа SuperSet */
d_setor(SUPERSET);
/* добавляем к ней Child'a*/
/* создаем - есс-но свежесозданная запись становится текущей */if (d_fillnew(CHILD, &child)!=S_OKAY) return CANNOT_CREATE_CHILD;
/* прилинковываем текущую запись к setу SuperSet */
d_connect(SUPERSET);
,где:
IMAINKEY — идентификатор поля Main::iMainKey
SUPERSET — идентификатор set'а SuperSet
Vista вообще генерирует ID для всех полей, записей, наборов.
// А вот это уже интересно — попытка получения метаинформации.. в 1984 г!
3.2) Как вы уже поняли, благодаря использованию такой дивной схемы, всякие там type safety,
reentrancy functions, multithreaded applications — это все не про нас, забудьте о них.
3.3) На десерт отдельным пунктом осветим способы поиска в БД.
Итак, доступные виды поиска:
— поиск по уникальному ключу
— поиск по неуникальному ключу
— поиск по записям
— поиск по дочерним записям в set'е
Разберем подробнее.
1) Поиск по уникальному ключу осуществляется с помощью функции
d_keyfind(int iFieldId, char * lpszValue);
Простейший случай. Ищет в мндексах, посему довольно быстро.
Если находит запись — делает ее текущей, нет — возвращает код ошибки;
2) Поиск по неуникальному ключу — индексу осуществляется с помощью функций:
d_keyfind, d_keyfrst, d_keynext, d_keyprev.
Пусть хранятся у нас данные в одном индексе: 0,1,2,3,4,5
00000000000111111111111112222222222344444444444555555
| <- key first
Нам нужно выбрать все записи с полем равным например, 2.
Для этого мы можем:
— воспользоваться связкой d_keyfind, d_keynext;
Функция d_keyfind всегда ищет только первую запись в индексе. То есть певая запись всегда найдется у вас достаточно быстро. Далее, пользуйте d_keynext и ручками проверяйте эквивалентность полей, другого выхода у вас нет. Это на самом деле плохой момент, означающий, что индексированные поля сравниваются не только при добавлении, но и при поиске.
— воспользоваться связкой d_keyfrst, d_keynext;
Эта связка дает уникальную возможность перебрать все записи в индексе.
Вдруг захочется пройтись по всему индексу, действительно...
3) поиск по записям
Случай, если индекса под рукой нет, а найти чего-нибудь очень хочется.
Используем знакомую схему:
d_recfrst( int iRecordId) - ищет первую запись
d_reclast( int iRecordId) - ищет последнюю запись
// iRecordId - сгенерированный Vist'ой Id-шник типа записи. ID_MAIN, например.
d_recnext() - переходит к следующей записи
d_recprev() - переходит к предыдущей записи
4) поиск по дочерним записям в setе
Алгоритм:
1) Устанавливаем текущую запись текущим владельцем для setа (см d_setor)
2) Используем функции:
d_findfm( SET) /* Find first member of SET */
d_findlm( SET) /* Find last member of SET */
d_findnm( SET) /* Find next member of SET */
d_findpm( SET) /* Find previous member of SET */
Комментарий: нет способа искать в set'е member'ы используя индексы.
Только полный перебор. Обидно. // тоже на самом деле серьезный ляп
При поиске 2-4 Вы сами, ручками, сравниваете нужные Вам поля записи по каким нибудь критериям. Тут вам поможет вся мощь стандартной библиотеки языка С.
Интересный подход к обеспечению безопасности приложения.
Некоторые функции, например d_open возвращают какие-то коды ошибок, это все даже описано в документации... Но реальность такова, что часто программа при ошибке просто вылетает с криком "Abort!" в STDOUT'е.
Нерасмотренными остались вопросы:
— организации транзакций;
— проблемы многопользовательской работы;
— блокировки и взаимоблокировки;
Thanks,
Ligen
//------------------ end
Ничего, люди пишут и на этой СУБД, а что делать, если проекты начинались в те еще времена. Действительно, герои..
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ЗХ>>>>ЗЫ: в текущем проекте у меня база с единственной таблицей [objId, propertyName, propertyValue]
ANS>>>А propertyValue это строка?
ЗХ>>В общем-то да, но база SQLite, у нее значения "почти нетипизированные" — insert ...values(1) — записал int, insert ...values(1.0) — float, insert ... values("1") — строку
ANS>Ясно. Меня этот подход смущяет именно ограниченной типизируемостью в случае "старших братьев".
Да ну понятно, что реляционная база для такого подхода не предназначена. Потому я и смайлик такой поставил
GZ>Что касается слухов смерти реляционных БД, то они несколько преувеличены. ... Лучше конечно без него, но нет ничего слишком криминального в этом, чтобы говорить о конце света.
Здравствуйте, Ligen, Вы писали:
L>Здравствуйте, Mamut, Вы писали:
M>>Я думаю, многие меня поддержат. Реляционные базы данных — это большой геморрой.
L>Это реляционные базы геморрой? Реляционные СУБД позволяют быстро и эффективно решать прорву вопросов. L>Для интересующихся привожу фрагмент своего давнего письма товарищам на тему сетевых БД, возникшего в результате спора, "а кто же круче".
API Raima dbVista действительно чревато многочисленными граблями. Но это отнюдь не является следствием сетевой модели. Это скорее из-за древности данной конкретной СУБД.
DD>ORM? с прозрачным persistance для объектов? Чем не вариант? Хотя получаем лишнюю прослойку... Конечно, если БД поддерживает такие операции напрямую, это гораздо интереснее... В этом смысле действительно будет интересно поразбираться с Cache'. Хотя опыт подсказывает, что и тут должны быть какие-то недостатки...
Имхо, любая проблема прослоек — это нестандартные ситуации или расширение чего-то уже существующего
В общем, опять хочется "чтобы я тыкнул в кнопочку, а оно заработало"
Здравствуйте, dshe, Вы писали:
D>API Raima dbVista действительно чревато многочисленными граблями. Но это отнюдь не является следствием сетевой модели. Это скорее из-за древности данной конкретной СУБД.
Допустим даже это.. как насчет привести в пример какую-нибудь классную реализацию сетевой модели? )
M>Представляете, да? При этом оператор должен видеть все эти резервации в списке, делать по ним выборку произвольным образом (а покажите-ка мне блочные резервации в отель Zurich с 15-го сентября сего года).
Ну и? В чем проблема-то?
M>Что самое интересное, в таком случае проблема не в обработке данных — что их там обрабатывать? Проблема — в самих данных. Что как и куда хранить? M>Проектировка базы — кошмар.
Почему?
M>Нормализация базы — еще тот геморрой. Расширение понятия "резервация"? Практически нереально (дополнительные таблицы, колонки, ключи...) Я конечно M>не спорю, многое зависит от кривых шаловливых ручек разработчика, но, имхо, рано или поздно приходишь к выводу, что пытаешься "впихнуть M>невпихуемое".
Может, дело не в реляционных базах — а в проектировщиках?
M>Может, ну ее, эту реляцию, к чертям? Ы?
Данивапрос. Храните во флэтфайлах — о результатах расскажите.
M>Вообще, чего мне вдруг стукнуло в голову — просто связь логики приложения и данных приложения, как таковая, отсутствует. А хоцца, чтоб не отсутствовала
Ну так наверное, надо проектировать так, что бы эта связь появилась? ORM там, паттерны всякие?
GZ>Законы теории ООП не совсем похожи на законы теории данных.
Только вот никаких законов ООП нету. Равно как и никакой строгой математики в основе.
Не более, чем удобный подход проектирования.
Здравствуйте, dmz, Вы писали:
M>>Вообще, чего мне вдруг стукнуло в голову — просто связь логики приложения и данных приложения, как таковая, отсутствует. А хоцца, чтоб не отсутствовала
dmz>Ну так наверное, надо проектировать так, что бы эта связь появилась? ORM там, паттерны всякие?
Далеко не каждое бизнес-правило можно описать при помощи средств СУБД. По крайней мере так, чтоб эту структуру данных можно было нормально использовать и изменять с минимальным перелопачиванием кода. Для этих целей существует слой бизнес-логики. Вот и получается, что бизнес-логика делается по принципу: что получится — делаем в СУБД (там и PL/SQL вспомним), что не получится — в слое бизнес-логики. ИМХО ничего хорошего в таком разделении нет.
GZ>Законы теории ООП не совсем похожи на законы теории данных. dmz>Только вот никаких законов ООП нету. Равно как и никакой строгой математики в основе. dmz>Не более, чем удобный подход проектирования.
Ага! На столько удобный, что стал популярен не менее чем SQL. ИМХО ООП требуется лишь время для появления хорошего языка описания ОО систем, может что-нибудь вроде низкоуровнего UML. А там может и строгую математику подведут.
M>>Представляете, да? При этом оператор должен видеть все эти резервации в списке, делать по ним выборку произвольным образом (а покажите-ка мне блочные резервации в отель Zurich с 15-го сентября сего года).
dmz>Ну и? В чем проблема-то?
Потому что блочные резервации, как резервации отдельного типа, мы храним в отдельной таблице, так? А если мне захотелось просмотреть все резервации для Zurich'a, да еще отсортированные по дате. Это уже, минимум три запроса в три таблицы с join'ами.
Ну, это еще простенько. А вот когда начинается сводка для бухгалтерии? И начинаются шаманские пляски с бубном вокруг трех типов резерваций (три таблицы), различными размерами коммисионных для разных отелей (связка двух таблиц), различные формы оплаты для отелей (связка отель-форма_оплаты-банк_if_credit_card), различные оплаты по отелям (HB/BB/Breakfast only, SNGL/DBL/TRPL/SNGL+Bosphorus View/DBL+Bosphorus View..., children(0-2,0-4,0-6,0-12...), ....). Кстати, о птичках, то есть о комнатах. Каждый отель выеживается по-своему. В The Marmara Istanbul, насколько я помню, 16 типов комнат и 4 плана для детей. В каком-нибудь мнэээ... Orsep или там Fahri — от силы 3 типа комнат (на обоих ) и дети все идут как 0-12 — бесплатно. Но дополнительную кровать в double (DBL+child) не поставят, берите triple по соответствующей цене.
Не забываем, что в зависимости от сезона цены меняются. Но не на все! Сьюты в 5-звездочных остаются по той же цене, например, а все остальное цены прыгают, куда хотят. А еще есть promotion от отелей, а еще есть даты проведения конгрессов или там Formula1, когда цены опять меняются.
А еще отели на Laleli имеют привычку менять цены, когда захотят.
А еще меняются комиссии по отелям.
А еще...
В общем, купили здесь в фирме спец. програмку для всего этого дела. 2 штуки вечнзеленых — одно рабочее место. В той программе, казалось бы, есть все — и трансферы, и гиды, и отели, и рестораны и..., и..., и... Оказалось не все. Компания согласилась дописать целый отдельный модуль, заточенный под специфику компании (гы, почти 30 мегабайтов апдейта, по-моему). Один модуль они наотрез отказались делать, говоря, что, увы, это невозможно. И, кстати, понятно, почему невозможно.
Когда нам предлагали другую программу, нам ее презентовал какой-то программер. Мы ему — а сделаешь то-то и то-то? Он пошевелил мозгами и сказал, что, мол, вы гоняете, это всю структуру базы данных менять надо.
ИМХО, насколько бы хорошо ни была спректирована база данных, расширение уже существующей системы будет проводится с большим скрипом — через введение каких-то левых таблиц, дополнительных многоэтажных запросов, дупликацию данных. И так далее. ИМХО. RDBMS хороши для заранее очерченной и четкой задачи, которая если и будет меняться, то незначительно.
Увы, лучшего пока не придумали Или придумали? *с надеждой*
M>>Что самое интересное, в таком случае проблема не в обработке данных — что их там обрабатывать? Проблема — в самих данных. Что как и куда хранить? M>Проектировка базы — кошмар. dmz>Почему?
M>>Нормализация базы — еще тот геморрой. Расширение понятия "резервация"? Практически нереально (дополнительные таблицы, колонки, ключи...) Я конечно M>не спорю, многое зависит от кривых шаловливых ручек разработчика, но, имхо, рано или поздно приходишь к выводу, что пытаешься "впихнуть M>невпихуемое".
dmz>Может, дело не в реляционных базах — а в проектировщиках?
M>>Может, ну ее, эту реляцию, к чертям? Ы? dmz>Данивапрос. Храните во флэтфайлах — о результатах расскажите.
GZ>>Законы теории ООП не совсем похожи на законы теории данных. dmz>Только вот никаких законов ООП нету. Равно как и никакой строгой математики в основе. dmz>Не более, чем удобный подход проектирования.
Более чем филосовский вопрос
И да и нет.
Сначало о математической модели. Математическая модель всегда абстрактна. Она не старается охватить сразу и все. Она просто идет по восходящей. Основная модель уточняется и уточняется. Поэтому мат. моделью ООП — может быть и машина Тьюринга. А более уточненная — модели структурного программирования. Этим насколько я помню занимался еще Дейкста. Все модели программирования были придуманы математиками. И именно Дейкстра, который был математиком, заметил что разбитие программ на более мелкие программы, значительно увеличивают понятность человеку.
Но шло время, математики нашли идеальные для себя модели. Это и функциональное программирование, и логическое, и автоматное, и событийное. Это методы программирования, которые точные модели которых легко описать. Математикам это нравилось. Но видишь ли какая штука. Не все что легко описывается математиками, легко воспринимается человеческим мозгом. И программисты как класс перестали быть математиками. Для них нужно было именно простота реализации. И будучи неподдержанными математиками они начали делать свои модели. Они начали делать не то что можно математически доказать, а то что удобно реализовать. И в результате, начали проигрывать математики. Они вырабатывали идеальные модели. Но эти идеальные мат. модели не использовались. Использовалось то, что удобно описать. Когда прочухались, было уже поздно. Они не просто пытались описать новые модели, которые были получены не ими. Они даже доказали неоптимальность такой модели. Есть такие термины как "подпорки" и "призраки". Они описаны именно математиками. А вот построить более четкую модель, того что сделано не ими, им не удалось.
Любая программа (независимо от того, функциональная или императивная) может быть описана графом. Но количество связей и их типы в программах императивных языков высокого уровня настолько велико, что однозначно ее описать если и можно, то бесполезно. Такая модель в силу ее сложности невозможно использовать.
Однако, изначально ставился вопрос, есть ли теория ООП? Да есть. Да она не покрывается полностью математикой. Да, она написана не математиками. Но она есть. И у нее есть свои законы. Просто в силу того, что математики забыли об ООП и не было крепкого фундамента, эти законы иногда трансформируются и дополняются(типа наследование как аксиома ООП). Но они есть.
Здравствуйте, Mazay, Вы писали:
M>Далеко не каждое бизнес-правило можно описать при помощи средств СУБД. По крайней мере так, чтоб эту структуру данных можно было нормально использовать и изменять с минимальным перелопачиванием кода. Для этих целей существует слой бизнес-логики. Вот и получается, что бизнес-логика делается по принципу: что получится — делаем в СУБД (там и PL/SQL вспомним), что не получится — в слое бизнес-логики. ИМХО ничего хорошего в таком разделении нет.
Бизнес-правила, не все. Это так. Но если использовать их по назначению, а именно для хранения данных, то реляционная модель может описать любую предметную область. Это математически доказанный факт.(Хотя также факт что есть области где РСУБД неэффективен).
Здравствуйте, Mamut, Вы писали:
M>Я думаю, многие меня поддержат. Реляционные базы данных — это большой геморрой. Возможно, ничего лучшего не придумано (?), но геморроем они от этого быть не перестают.
У меня есть большое подозрение, что ты сложность объектной модели переносишь на проблемы РСУБД.
M>Два раза мне приходилось работать над проектами (и оба раза — неудачными ), где велась работа с разнообразными, но _родственными_ объектами. Или объектами, различающимися в одном свойстве, но от этого свойства изменялась логика работы приложения.
И это конечно же были разные таблицы?
M>Пример M>Имеем туристическую компанию, резервирующую места в отелях. Казалось бы, что может быть проще?
Действительно, пока имеем три таблицы
M>Резервации могут быть поименно/пономерно. Могут быть списком в n человек на заранее зарегистрированные номера. могут быть блоком (20 SNGL, 10 DBL, 5 TRPL) комнат на будущее.
Вырисовалась ещё одна таблица для объединения резерваций.
M>Могут быть с полным питанием (Full Board, BB), могут быть с половинным (HB).
Это всё атрибуты.
M>Могут быть с детьми (у разных отелей — разная политика на детей, например 0-6 бесплатно, 6-12 50% скидка или 0-4 бесплатно, 4-8 50%, 8-12 25%)
Это тоже атрибуты.
M>Могут попадать на межсезонье в отеле (половина — по одной цене, вторая половина — по другой, завышенной, а что делать — например Формула 1 проходит)
Это тоже атрибуты. Но пару таблиц для задания подобных расписаний добавить можно
M>Представляете, да?
Аж 6 таблиц! Ну ладно, давай округлим до 12-ти
M>При этом оператор должен видеть все эти резервации в списке, делать по ним выборку произвольным образом (а покажите-ка мне блочные резервации в отель Zurich с 15-го сентября сего года).
Проблемы юзабилити тоже уже стали проблемами реляционных БД?
M>Что самое интересное, в таком случае проблема не в обработке данных — что их там обрабатывать? Проблема — в самих данных. Что как и куда хранить? Проектировка базы — кошмар. Нормализация базы — еще тот геморрой. Расширение понятия "резервация"? Практически нереально (дополнительные таблицы, колонки, ключи...) Я конечно не спорю, многое зависит от кривых шаловливых ручек разработчика, но, имхо, рано или поздно приходишь к выводу, что пытаешься "впихнуть невпихуемое".
Да уж.
M>Может, ну ее, эту реляцию, к чертям? Ы?
Что-то одно из двух точно надо к чертям, либо реляцию, либо объектность. А лучше сразу обе и остановиться где-нибудь посередине Кстати, а объектной моделью ты доволен?
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
M>Далеко не каждое бизнес-правило можно описать при помощи средств СУБД. По крайней мере так, чтоб эту структуру данных можно было нормально M>использовать и изменять с минимальным перелопачиванием кода. Для этих целей существует слой бизнес-логики. Вот и получается, что бизнес-логика M>делается по принципу: что получится — делаем в СУБД (там и PL/SQL вспомним), что не получится — в слое бизнес-логики. ИМХО ничего хорошего в таком M>разделении нет.
Ну, я согласен, что бывают проблемы — но пока большинство из них решалось. В любом случае, внятных альтернатив пока нет.
M>Ага! На столько удобный, что стал популярен не менее чем SQL. ИМХО ООП требуется лишь время для появления хорошего языка описания ОО систем, может
Это ортогональные вещи. Вы запросы как собираетесь делать без SQL? Свой язык запросов придумывать?
M>что-нибудь вроде низкоуровнего UML. А там может и строгую математику подведут.
Пока не удалось. Равно как и не удалось сделать ОО хранилища настолько же универсальными и надежными,
как SQL.
Здравствуйте, Mamut, Вы писали:
M>>>Представляете, да? При этом оператор должен видеть все эти резервации в списке, делать по ним выборку произвольным образом (а покажите-ка мне блочные резервации в отель Zurich с 15-го сентября сего года).
dmz>>Ну и? В чем проблема-то?
M>Потому что блочные резервации, как резервации отдельного типа, мы храним в отдельной таблице, так? А если мне захотелось просмотреть все резервации для Zurich'a, да еще отсортированные по дате. Это уже, минимум три запроса в три таблицы с join'ами.
Не готов я рассматривать эту задачу на уровне дизайна, потому что тут надо много думать, перед тем как что-то
предложить — слёту я такие вещи как-то не привык делать. Поэтому ограничусь тезисами:
1) при проектировании систем с большим количеством данных соображения производительности должны
превалировать над соображениями правильности — в частности, можно сознательно пойти на денормализацию
2) если вся работа с базой осуществляется через ORM layer — и никто не лазит в обход него, то урон от денормализации
может быть сведен к нулю
3) в запросе по трём таблицам с джойнами нет особых проблем, если построены индексы — так?
M>Ну, это еще простенько. А вот когда начинается сводка для бухгалтерии? И начинаются шаманские пляски с бубном вокруг трех типов резерваций (три таблицы), различными размерами коммисионных для разных отелей (связка двух таблиц), различные формы оплаты для отелей (связка
Вы сейчас рассказываете про неудобства выбранной модели, но ведь никто не сказал, что она оптимальна.
M>А еще отели на Laleli имеют привычку менять цены, когда захотят. M>А еще меняются комиссии по отелям. M>А еще...
Кто сказал, что есть или будет что-то, что снимет решение этих задач с проектировщика?
There isno silver bullet. Просто сложная предметная область — какой бы инструмент не выбрали, голову
поморочить придется.
M>ИМХО, насколько бы хорошо ни была спректирована база данных, расширение уже существующей системы будет проводится с большим скрипом — через M>введение каких-то левых таблиц, дополнительных многоэтажных запросов, дупликацию данных. И так далее. ИМХО. RDBMS хороши для заранее очерченной M>и четкой задачи, которая если и будет меняться, то незначительно.
Не согласен. Я полгода как не занимаюсь разработкой приложения для трейдинга — там была оракловая база таблиц на 250,
как со статическими так и динамическими данными — макс. количество строк в таблице — около 19 миллионов.
База модифицировалась практически в каждом релизе — а релизы бывали раз в неделю — раз в две недели — обычно добавлялись
новые поля, но бывало всякое. Никаких проблем с модификацией базы не было — ALTER TABLE ADD COLUMN операция почти бесплатная,
OR Layer генерировался автоматически из модели данных, скрипты для модификации базы — полуавтоматически (ессно, я их прогонял на тестовой среде)
Принципиальных проблем не было.
M>Увы, лучшего пока не придумали Или придумали? *с надеждой*
Нет.
M>>>Нормализация базы — еще тот геморрой. Расширение понятия "резервация"? Практически нереально (дополнительные таблицы, колонки, ключи...) Я конечно M>не спорю, многое зависит от кривых шаловливых ручек разработчика, но, имхо, рано или поздно приходишь к выводу, что пытаешься "впихнуть M>невпихуемое".
Ну, может не стоит так уж гнаться за нормализацией? Может быть, не рассматривать это как самоцель?
GZ>Однако, изначально ставился вопрос, есть ли теория ООП? Да есть. Да она не покрывается полностью математикой. Да, она написана не математиками. GZ>Но она есть. И у нее есть свои законы.
Тут разница такая же, как между законами природы и уголовным кодексом.
Законы природы просто работают, а уголовный кодекс надо чтить.
Здравствуйте, Mazay, Вы писали: M>Ага! На столько удобный, что стал популярен не менее чем SQL. ИМХО ООП требуется лишь время для появления хорошего языка описания ОО систем, может что-нибудь вроде низкоуровнего UML. А там может и строгую математику подведут.
Ага. Только математики ещё не знают, что им предстоит.
Поздно вспомнили про математику. В школе надо было её учить, в школе.
Здравствуйте, Mamut, Вы писали: M>>>Представляете, да? При этом оператор должен видеть все эти резервации в списке, делать по ним выборку произвольным образом (а покажите-ка мне блочные резервации в отель Zurich с 15-го сентября сего года). dmz>>Ну и? В чем проблема-то? M>Потому что блочные резервации, как резервации отдельного типа, мы храним в отдельной таблице, так? А если мне захотелось просмотреть все резервации для Zurich'a, да еще отсортированные по дате. Это уже, минимум три запроса в три таблицы с join'ами.
union all этих таблиц.
Здравствуйте, GlebZ, Вы писали: GZ>Но шло время, математики нашли идеальные для себя модели. Это и функциональное программирование, и логическое, и автоматное, и событийное. Это методы программирования, которые точные модели которых легко описать. Математикам это нравилось. Но видишь ли какая штука. Не все что легко описывается математиками, легко воспринимается человеческим мозгом.
Из чего можно сделать вывод, что у математиков вместо мозгов — ...
Здравствуйте, Mamut, Вы писали:
M>Возможно, вопрос поставлен слишком жестко, но все же.
Самое забавное, но я в свое время думал именно в сторону туристического бизнеса в плане обоснования необходимости применять ООСУБД.
Собственно, то, что ты пока что рассказал, ничего сложного не представляет. Ну да, довольно таки разветвленная структура таблиц. Нудно, но не сложно. Просто сидишь и методично выписываешь все атрибуты...
Сложность — в выполнении запроса "выведи мне все предложения, удовлетворяющие вот-тому то". Ну типа "семья из двух человек с ребенком хочет отдохнуть на побережье греции". И сортировать надо по стоимости. С учетом всех этих безумных pricing rules. Даже расчет стоимости авиаперелета плохо делается автоматом. У нас так до сих пор вручную все делают. И бывают потом конфликты с авиакомпанией, когда оператор выдает билет по несуществующему тарифу.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
M>>Ага! На столько удобный, что стал популярен не менее чем SQL. ИМХО ООП требуется лишь время для появления хорошего языка описания ОО систем, может dmz>Это ортогональные вещи. Вы запросы как собираетесь делать без SQL? Свой язык запросов придумывать?
Был такой язык -- Object Query Language назывался. Почил в бозе вместе с породившим его стандартом ODMG.
M>>что-нибудь вроде низкоуровнего UML. А там может и строгую математику подведут. dmz>Пока не удалось. Равно как и не удалось сделать ОО хранилища настолько же универсальными и надежными, dmz>как SQL.
Надежность OO хранилищи не хуже надежности SQL баз. И не выше, чем надежность железа, на котором СУБД работает
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, fplab, Вы писали:
F>Здравствуйте, Mamut, Вы писали:
F>Альтернативы в студию. Есть такая штука как Cache, говорят хорошая вещь.
Объектно-ориентированная, но сам движок сделан на реляционой =)
Самый большой недостаток: пока размер базы меньше размера оперативки(то бишь вся база в кэше) то все летает, но как только начинаются дисковые операции из-за того, что база разрослась, так все — "мама роди меня обратно" — начинаешь тоскливо озираться в сторону Oracle.
Здравствуйте, Ligen, Вы писали:
L>Здравствуйте, dshe, Вы писали:
D>>API Raima dbVista действительно чревато многочисленными граблями. Но это отнюдь не является следствием сетевой модели. Это скорее из-за древности данной конкретной СУБД.
L>Допустим даже это.. как насчет привести в пример какую-нибудь классную реализацию сетевой модели? )
Не приведу. Во-первых, потому что не интересовался этим вопросом, а во-вторых, должно быть такой и нет просто потому, что РСУБД значительно обогнали в своем развитии сетевые и обросли фичами, которые не присущи оригинальной реаляционной модели.
В целом, проектирование сетевой базы не отличается радикально от проектирования реляционной. И там и там определяется набор сущностей и связей между ними. Каждой сущности будет соответствовать своя таблица (record в dbVista) а связи выражаются при помощи ключей в РСУБД или set'ов в dbVista. При таком подходе, в РСУБД отношения оказываются в нормализованном виде как-то сами собой. Не знаю, пользуется ли вообще кто-то формальным подходом реляционной модели при котором берется сначала ненормализованное отношение, а потом приводится постепенно к нормальной форме необходимой степени?
Кстати, многие (если уже не все) РСУБД обладают поддержкой foreign key constraint. Это немного роднит их с сетевыми поскольку в самой идее сетевой модели изначально подразумевается валидация и контроль связей между записями.
А насчет dbVista'вского API, то его можно было обернуть в более удобоваримый вид, решающий проблемы с multithreading, type safety и прочее...
Здравствуйте, dshe, Вы писали: D>Кстати, многие (если уже не все) РСУБД обладают поддержкой foreign key constraint. Это немного роднит их с сетевыми поскольку в самой идее сетевой модели изначально подразумевается валидация и контроль связей между записями.
Разве сетевые БД не есть РСУБД + foreign key constraint — SQL?
dmz>>Это ортогональные вещи. Вы запросы как собираетесь делать без SQL? Свой язык запросов придумывать?
E>Был такой язык -- Object Query Language назывался. Почил в бозе вместе с породившим его стандартом ODMG.
Он не один был. По семантике — бледное подражание SQL. В общем, неспроста они окочурились.
M>>>что-нибудь вроде низкоуровнего UML. А там может и строгую математику подведут. dmz>>Пока не удалось. Равно как и не удалось сделать ОО хранилища настолько же универсальными и надежными, dmz>>как SQL.
E>Надежность OO хранилищи не хуже надежности SQL баз. И не выше, чем надежность железа, на котором СУБД работает
Для реляционных баз, как-то Оракла, есть такие решения, как RAC. Есть ли что-то подобное для OO баз?
Н-да? Можно примеры реализации каких-нибудь больших систем на основе OODBMS ? Что-нибудь типа биллинга,
еще-то нибудь? Вот у нас, например, тут на оракле стоит препейдная система (ну, биллинг, короче — что бы не заморачиваться)
— там есть таблица с количеством записей — сотни миллионов. Работает в почти-рилтайме, жестко соблюдается максимальное время
ответа для некоторых операций (менее 5 секунд). Что-нибудь подобное можно организовать на OODBMS?
А data mining? Есть ли язык запросов, по возможностям близкий к SQL? Построение произвольных отчетов,
не путем генерации и использования каких-то API, а путем простого написания запросов?
<SKIP> M>Увы, лучшего пока не придумали Или придумали? *с надеждой*
<SKIP> M> Месье знает толк в извращениях
Месье, попробуйте отделить мушек о котлеток и поставить между ними какой-нибудь грамотный OR-bridge и сдается мне что вас потом практически перестанет интересовать вопрос где и как храняться ваши данные.
Здравствуйте, beroal, Вы писали:
B>Здравствуйте, dshe, Вы писали: D>>Кстати, многие (если уже не все) РСУБД обладают поддержкой foreign key constraint. Это немного роднит их с сетевыми поскольку в самой идее сетевой модели изначально подразумевается валидация и контроль связей между записями. B>Разве сетевые БД не есть РСУБД + foreign key constraint — SQL?
Насколько я понимаю, разница между сетевой и реляционной во внутренней реализации. Допустим у нас есть сущности Group и Member со связью между ними Contains (типа Group Contains Member). То в dbVista (и любой другой сетевой СУБД) каждая запись Group содержит неявно ссылку на первый Member из списка дочерних (т.е. тех, которые находятся в одной связи с данной записью Group), а каждая запись Member содержит ссылку на родительскую запись Group + ссылку на следующую запись Member в списке дочерних. Это дает возможнось за одну операцию чтения (как уже говорилось) производить навигацию по данным записям.
В реляционной БД запись Group будет содержать первичный ключ, а запись Member внешний ключ на соответствующую запись Group. В реляционной модели -- связи неявные и в принципе можно связать даже то, что по смыслу несвязуемое. Подобная гибкость и позиционируется как достоинство реляционной модели. В сетевой модели производить навигацию по тому, что не было изначально задумано как связанное, требует бОльших усилий.
Что касается SQL, то в dbVista есть какая-то надстройка, которая позволяет делать некоторые select'ы с учетом set'ов. Хотя, конечно, эта СУБД больше ориентирована на навигацию по отдельным записям.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Разве? Там навроде движок MUMPS. А реляционка сверху прикручена.
Точно, мумпс — это иерархическая субд (такие были до реляционных)(одна из проблем — это для того, чтобы по порядку выбрать записи "таблицы", нужно было подниматься по ссылке к родителю, выбирать следующую ссылку, и по ней опускаться обратно). к ней прикручены интерфейсы sql и ооп.
Здравствуйте, GlebZ, Вы писали:
M>>Далеко не каждое бизнес-правило можно описать при помощи средств СУБД.
GZ>Бизнес-правила, не все. Это так. Но если использовать их по назначению, а именно для хранения данных, то реляционная модель может описать любую предметную область. Это математически доказанный факт.(Хотя также факт что есть области где РСУБД неэффективен).
Не сомневаюсь. Но сегодня мало просто описать. Нужно описать так, чтоб можно было легко и просто изменять. Причём желательно с минимальным вмешательством программиста. Реляционные структуры данных очень негибкие. Именно об этом говорит Mamut здесь
, именно эти проблемы призваны решить различные workflow системы. В идеале все изменения (любой сложности) в бизнес-логику системы должны вностится пользователями. Сейчас делаются попытки создать язык (например BPEL), который будет понятен как владельцу процесса, так и программисту. А ещё лучше не программисту, а самой системе. Основная сложность при создании токго языка в том, что он должен быть достаточно сложен чтобы описать предметную область и достаточно легко формализуем.
Сейчас программисты пытаются создать подобие такого "языка" в РСУБД. Вот Зверёк пишет: ЗХ> ЗЫ: в текущем проекте у меня база с единственной таблицей [objId, propertyName, propertyValue]
Кто-то рисует структуры посложнее, но при этом приобретает геморрой с сохранением универсальности/адаптируемости и риск, что в один прекрасный день новое бизнес-правило невозможно будет описать в этой структуре данных и придётся вносить в неё изменения. Может и удастся создать достаточно универсальную структуру данных, в которой все изменения бизнес-логики будут отражать только добавлением записей, а не правкой триггеров/хранимых процедур и применением ALTER TABLE.
С объектами же программисты привыкли делать всё, что им заблагорассудится. Можно задать самое извращённое поведение объекта, даже научить его понимать какой-нить язык описания ограничений или запросов. Для полного счастья программисту нужен ОДИН движок в котором он мог бы описать ВСЮ бизнес-логику программы и на любые извращённые запросы заказчика отвечать правкой пары строк в коде (может и на каком-нибудь OQL). Или просто обучить заказчика использованию BPEL (или что там будет).
Здравствуйте, Зверёк Харьковский, Вы писали:
ЗХ>2. Основное преимущество реляционных баз данных — функциональный SQL; лучше которого для запроса к данным еще не придумано. Его вон даже MS в C# 3.0 имитирует
Здравствуйте, dmz, Вы писали:
dmz>>>Это ортогональные вещи. Вы запросы как собираетесь делать без SQL? Свой язык запросов придумывать?
E>>Был такой язык -- Object Query Language назывался. Почил в бозе вместе с породившим его стандартом ODMG. dmz>Он не один был. По семантике — бледное подражание SQL. В общем, неспроста они окочурились.
M>>>>что-нибудь вроде низкоуровнего UML. А там может и строгую математику подведут. dmz>>>Пока не удалось. Равно как и не удалось сделать ОО хранилища настолько же универсальными и надежными, dmz>>>как SQL.
E>>Надежность OO хранилищи не хуже надежности SQL баз. И не выше, чем надежность железа, на котором СУБД работает dmz>Для реляционных баз, как-то Оракла, есть такие решения, как RAC. Есть ли что-то подобное для OO баз?
dmz>Н-да? Можно примеры реализации каких-нибудь больших систем на основе OODBMS ? Что-нибудь типа биллинга, dmz>еще-то нибудь? Вот у нас, например, тут на оракле стоит препейдная система (ну, биллинг, короче — что бы не заморачиваться) dmz>- там есть таблица с количеством записей — сотни миллионов. Работает в почти-рилтайме, жестко соблюдается максимальное время dmz>ответа для некоторых операций (менее 5 секунд). Что-нибудь подобное можно организовать на OODBMS?
dmz>А data mining? Есть ли язык запросов, по возможностям близкий к SQL? Построение произвольных отчетов, dmz>не путем генерации и использования каких-то API, а путем простого написания запросов?
Скоро только кролики плодятся. Не знаю сколько лет SQL'у, но явно больше чем OQL. На SystemR надо полагать тоже сначала не ЦУП'ы работали. И сейчас никто кажется не предлагает программу массового перехода на ООСУБД за 3 года. Будет потребность бизнеса — решатся любые проблеммы.
Здравствуйте, Mazay, Вы писали: M> С объектами же программисты привыкли делать всё, что им заблагорассудится. Можно задать самое извращённое поведение объекта, даже научить его понимать какой-нить язык описания ограничений или запросов. Для полного счастья программисту нужен ОДИН движок в котором он мог бы описать ВСЮ бизнес-логику программы и на любые извращённые запросы заказчика отвечать правкой пары строк в коде (может и на каком-нибудь OQL). Или просто обучить заказчика использованию BPEL (или что там будет).
Если быть до конца честным, бледное подобие таких движков есть, а именно, я говорю о алгоритмических языках, встроенных в СУБД. Конечно, GUI на них писать пока ещё рано... Хотя есть PostgreSQL, где границы между своим и чужим ЯП практически стёрты.
Здравствуйте, AndrewVK, Вы писали:
ЗХ>>2. Основное преимущество реляционных баз данных — функциональный SQL; лучше которого для запроса к данным еще не придумано. Его вон даже MS в C# 3.0 имитирует
.
AVK>По семантике LINQ ближе к XPath,
Если не лень, можешь показать пару примеров (в смысле, где семантика ближе к XPath нежели к SQL)?
AVK>хотя синтаксически действительно похож на SQL.
почему я и сказал "имитирует"
ЗЫ: Вообще, мне кажется (со стороны), что C# пошел интересным путем — он постепенно превращается из цельного языка в набор DSL'ей. Нет?
Здравствуйте, dmz, Вы писали:
M>>>>что-нибудь вроде низкоуровнего UML. А там может и строгую математику подведут. dmz>>>Пока не удалось. Равно как и не удалось сделать ОО хранилища настолько же универсальными и надежными, dmz>>>как SQL.
E>>Надежность OO хранилищи не хуже надежности SQL баз. И не выше, чем надежность железа, на котором СУБД работает dmz>Для реляционных баз, как-то Оракла, есть такие решения, как RAC. Есть ли что-то подобное для OO баз?
Я не в курсе, что такое RAC
dmz>Н-да? Можно примеры реализации каких-нибудь больших систем на основе OODBMS ?
Не правда ли странно, что самая большая в мире БД работает на основе ООСУБД Objectivity.
dmz> Что-нибудь типа биллинга, dmz>еще-то нибудь? Вот у нас, например, тут на оракле стоит препейдная система (ну, биллинг, короче — что бы не заморачиваться) dmz>- там есть таблица с количеством записей — сотни миллионов. Работает в почти-рилтайме, жестко соблюдается максимальное время dmz>ответа для некоторых операций (менее 5 секунд). Что-нибудь подобное можно организовать на OODBMS?
Я думаю, что без проблем. Даже на Berkeley DB можно сделать время операции меньше 5 секунд на таблицах с миллионами элементов
Многие производители ООСУБД хвастались, что на их основе реализованы различные решения для бирж, которые работают в рилтайме.
dmz>А data mining? Есть ли язык запросов, по возможностям близкий к SQL? Построение произвольных отчетов, dmz>не путем генерации и использования каких-то API, а путем простого написания запросов?
Вообще-то я заступился за надежность ООСУБД, а не за универсальность
Для меня РСУБД просто на несколько порядков универсальнее, чем ООСУБД. С этим бесполезно спорить.
Другое дело, что когда сталкиваешься с задачей, которую сложно впихнуть в РСУБД, то вся их универсальность не стоит и копейки. Именно поэтому есть области, где ООСУБД себя чувствуют нормально, не испытывая конкуренции со стороны других систем.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
E>Не правда ли странно, что самая большая в мире БД работает на основе ООСУБД Objectivity.
Надо изучить. Не убежден, что она самая большая в мира
dmz>> Что-нибудь типа биллинга, dmz>>еще-то нибудь? Вот у нас, например, тут на оракле стоит препейдная система (ну, биллинг, короче — что бы не заморачиваться) dmz>>- там есть таблица с количеством записей — сотни миллионов. Работает в почти-рилтайме, жестко соблюдается максимальное время dmz>>ответа для некоторых операций (менее 5 секунд). Что-нибудь подобное можно организовать на OODBMS?
E>Я думаю, что без проблем. Даже на Berkeley DB можно сделать время операции меньше 5 секунд на таблицах с миллионами элементов E>Многие производители ООСУБД хвастались, что на их основе реализованы различные решения для бирж, которые работают в рилтайме.
Да-да. Именно. Я лично не так давно уволился из одной такой конторы, где было именно решение для биржи
и работало оно именно в рилтайме. Была именно OO-база — ну, по крайней мере в видении разработчиков.
Всем хорошая база, только хранила данные только за три дня торгов — иначе капец. Все остальное перекачивалось в
Оракл, а мега-OO база транкейтилась.
Кстати, я бы посмотрел как Беркли будет работать с сотней миллионов записей. Действительно интересно — может, нам
надо на Беркли смигрировать? Столько денег съэкономим на Оракловом суппорте...
E>Вообще-то я заступился за надежность ООСУБД, а не за универсальность E>Для меня РСУБД просто на несколько порядков универсальнее, чем ООСУБД. С этим бесполезно спорить.
Да — но вопрос, не являются примеры успешного применения OORDBMS на самом деле примерами успеха
применения баз данных, специально разработанных под задачу. Конечно, такие решения должны выигрывать
по каким-то параметрам у универсальных решений.
E>Другое дело, что когда сталкиваешься с задачей, которую сложно впихнуть в РСУБД, то вся их универсальность E>не стоит и копейки. Именно поэтому есть E>области, где ООСУБД себя чувствуют нормально, не испытывая E>конкуренции со стороны других систем.
Да — но тут надо смотреть внимательно, можно впихнуть или нельзя. Главное — не делать поспешных выводов.
Слишком дорого иначе может обойтись.
В общем, я лично не спорю, что есть области, где ОО СУБД или специально разработанные СУБД выигрывают — но буду
утверждать, что в 90% случаев разумнее применять реляционные — в силу зрелости технологии, наличия инструментов,
etc, etc.
Здравствуйте, Зверёк Харьковский, Вы писали:
AVK>>По семантике LINQ ближе к XPath, ЗХ>Если не лень, можешь показать пару примеров (в смысле, где семантика ближе к XPath нежели к SQL)?
Лень
Вот к примеру такой код:
new XElement("Customers",
from c in contacts.Elements("contact")
select new XElement("Customer",
new XElement("Name", (string) c.Element("name")),
new XElement("PhoneNumbers",
from ph in c.Elements("phone")
select new XElement("phone", (string) ph,
ph.Attribute("type")
)
)
)
);
Здравствуйте, Mazay, Вы писали:
M> Реляционные структуры данных очень негибкие.
Да, не идеал, но с объектами все еще грустнее..
M> С объектами же программисты привыкли делать всё, что им заблагорассудится.
Угу, а знаешь почему? Потому что объект != данные. Объект — это поведение, данные же остаются неизменными, отсюда и возникает эта невиданная простота и легкость. Сегодня мы данные трактуем так — у нас один объект, завтра надо по другому — не вопрос, объект поменяли, данные остались. А как только мы пытаемся работать с данными как с объектами, то тут же вся гибкость идет лесом и на поверку оказывается, что реляционное представление данных, на данный момент, по гибкости еще никому превзойти не удалось, не смотря на то что из соображений производительности приходится в некоторой степени завязывать струтуру БД на семантику данных.
M> Для полного счастья программисту нужен ОДИН движок в котором он мог бы описать ВСЮ бизнес-логику программы и на любые извращённые запросы заказчика отвечать правкой пары строк в коде (может и на каком-нибудь OQL).
Нет, в коде это еще не идеал. Заказчик должен кубики и стрелочки на экране передвигать.
E>>Не правда ли странно, что самая большая в мире БД работает на основе ООСУБД Objectivity. dmz>Надо изучить. Не убежден, что она самая большая в мира
Найдешь больше -- сообщи сюда, пусть все узнают.
E>>Вообще-то я заступился за надежность ООСУБД, а не за универсальность E>>Для меня РСУБД просто на несколько порядков универсальнее, чем ООСУБД. С этим бесполезно спорить. dmz>Да — но вопрос, не являются примеры успешного применения OORDBMS на самом деле примерами успеха dmz>применения баз данных, специально разработанных под задачу. Конечно, такие решения должны выигрывать dmz>по каким-то параметрам у универсальных решений.
Именно так и происходит. Под некоторые задачи ООБД очень хорошо подходят. Настолько хорошо, что без них задача бы не решалась вовсе (за отведенное время и бюджет).
dmz>В общем, я лично не спорю, что есть области, где ОО СУБД или специально разработанные СУБД выигрывают — но буду dmz>утверждать, что в 90% случаев разумнее применять реляционные — в силу зрелости технологии, наличия инструментов, dmz>etc, etc.
+1
Именно такой же позиции и я придерживаюсь.
Только будучи разработчиком собственной ООСУБД мне интересны как раз оставшиеся 10% случаев
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Mazay, Вы писали:
M>Не сомневаюсь. Но сегодня мало просто описать. Нужно описать так, чтоб можно было легко и просто изменять.
Нет нужно просто правильно описывать. M>Причём желательно с минимальным вмешательством программиста. Реляционные структуры данных очень негибкие. Именно об этом говорит Mamut здесь
, именно эти проблемы призваны решить различные workflow системы.
Там проблема в ДНК. База данных которая создана программистами, и БД созданная архитекторами — две разные вещи. О нужности разделение логической структуры БД и физической — пишется в каждой книге. Этого не было сделано. Ну и получили то, к чему стремились.
M>В идеале все изменения (любой сложности) в бизнес-логику системы должны вностится пользователями. Сейчас делаются попытки создать язык (например BPEL), который будет понятен как владельцу процесса, так и программисту. А ещё лучше не программисту, а самой системе. Основная сложность при создании токго языка в том, что он должен быть достаточно сложен чтобы описать предметную область и достаточно легко формализуем.
UML — был построен с примерно такими же требованиями. Какая фигня получилась, уже говорено переговорено.
M> Сейчас программисты пытаются создать подобие такого "языка" в РСУБД. Вот Зверёк пишет: ЗХ>> ЗЫ: в текущем проекте у меня база с единственной таблицей [objId, propertyName, propertyValue]
M>Кто-то рисует структуры посложнее, но при этом приобретает геморрой с сохранением универсальности/адаптируемости и риск, что в один прекрасный день новое бизнес-правило невозможно будет описать в этой структуре данных и придётся вносить в неё изменения. Может и удастся создать достаточно универсальную структуру данных, в которой все изменения бизнес-логики будут отражать только добавлением записей, а не правкой триггеров/хранимых процедур и применением ALTER TABLE.
Зачем? У тебя есть реляционная структура которая доказанно универсальна. Она уже готовая. Зачем вводить новую универсальность? Да, при изменении бизнес-логики придется править реляционную модель. Это один из ее недостатков. Но существует теорема о невозможности универсальной функции. Зачем ее опровергать?
M> С объектами же программисты привыкли делать всё, что им заблагорассудится. Можно задать самое извращённое поведение объекта, даже научить его понимать какой-нить язык описания ограничений или запросов. Для полного счастья программисту нужен ОДИН движок в котором он мог бы описать ВСЮ бизнес-логику программы и на любые извращённые запросы заказчика отвечать правкой пары строк в коде (может и на каком-нибудь OQL).
Если говорить о недостатках РСУБД, то могу сходу назвать следующие: невозможность менять модель в runtime(точнее неэффективность изменения схемы), неэффективность при многомерных запросах, отсутсвие недекларативного навигационного доступа, ну и проблемы дубликатов, хотя это не проблема реляционной теории, а проблема именно SQL. Что касается многомерных запросов, то дополнительные инструменты уже придумали, OLAP(и кстати описал не кто иной как Кодд). В OODB, хотя она вынуждает пользователя выполнять именно такие запросы, проблема полностью не решена.
Здравствуйте, Merle, Вы писали:
M>> С объектами же программисты привыкли делать всё, что им заблагорассудится. M>Угу, а знаешь почему? Потому что объект != данные. Объект — это поведение, данные же остаются неизменными, отсюда и возникает эта невиданная простота и легкость. Сегодня мы данные трактуем так — у нас один объект, завтра надо по другому — не вопрос, объект поменяли, данные остались. А как только мы пытаемся работать с данными как с объектами, то тут же вся гибкость идет лесом и на поверку оказывается, что реляционное представление данных, на данный момент, по гибкости еще никому превзойти не удалось, не смотря на то что из соображений производительности приходится в некоторой степени завязывать струтуру БД на семантику данных.
Мои 5 копеек, в Oracle есть Object, у него даже есть методы, но они не привязаны к экземпляру ( если так можно выразиться ). И в целом от этого одни проблемы ИМХО.
Здравствуйте, ansi, Вы писали: A>Здравствуйте, beroal, Вы писали: B>>Из чего можно сделать вывод, что у математиков вместо мозгов — ... A>Сам такой
От вы меня поняли полностью наоборот. Я хотел сказать, что если математик может придумать что-то, что не может понять человеческий мозг, значит у математика мозг уже нечеловеческий?
S>Самое забавное, но я в свое время думал именно в сторону туристического бизнеса в плане обоснования необходимости применять ООСУБД. S>Собственно, то, что ты пока что рассказал, ничего сложного не представляет. Ну да, довольно таки разветвленная структура таблиц. Нудно, но не сложно. Просто сидишь и методично выписываешь все атрибуты... S>Сложность — в выполнении запроса "выведи мне все предложения, удовлетворяющие вот-тому то". Ну типа "семья из двух человек с ребенком хочет отдохнуть на побережье греции". И сортировать надо по стоимости. С учетом всех этих безумных pricing rules. Даже расчет стоимости авиаперелета плохо делается автоматом. У нас так до сих пор вручную все делают. И бывают потом конфликты с авиакомпанией, когда оператор выдает билет по несуществующему тарифу.
6. If you want to do a simple round-trip from BOS to LAX in two weeks, coming back in three, willing to entertain a 24 hour departure window for both parts, then limiting to "reasonable" routes (at most 3 flights and at most 10 hours or so) you have about 5,000 ways to get there and 5,000 ways to get back. Listing them is a mostly trivial graph-search (there are a few minor complications, but not many), that anybody could do in a fraction of a second.
7. The real challenge is that a single fixed itinerary (a fixed set of flights from BOS to LAX and a fixed set back) with only two flights in each direction may have more than 10,000 possible combinations of applicable "fares", each fare with complex restrictions that must be checked against the flights and the other fares. That means that the search space for this simple trip is of the order 5000 x 5000 x 10000, and a naive program would need to do a _lot_ of computation just to validate each of these possibilities. Suitably formalized, its not even clear that the problem of finding the cheapest flight is NP-complete
Кстати, наблюдал собственными глазами в ticket отделе следующую ситуацию. Какой-то мужик хотел полететь из Стамбула в Петербург обязательно через Осло с остановкой в Вене Оператор пыталась заставить систему (Amadeus) выдать остановку в Осло меньше, чем 24 часа Не помню, чем все это закончилось. По-моему, 8-часовой остановкой в Вене.
Если в следующий раз при поездке в Турцию вас поселят не в том отеле, не удивляйтесь
Здравствуйте, Ligen, Вы писали:
L>Здравствуйте, dshe, Вы писали:
D>>API Raima dbVista действительно чревато многочисленными граблями. Но это отнюдь не является следствием сетевой модели. Это скорее из-за древности данной конкретной СУБД.
L>Допустим даже это.. как насчет привести в пример какую-нибудь классную реализацию сетевой модели? )
IMS (Information Management System) — наиболее старая СУБД фирмы IBM. Она поддерживает иерархическую модель данных... (не очень классная, но куда "древней" dbVista)
СУБД ADABAS/NATURAL — это мультимодельная система, позволяющая строить иерархические, сетевые и SQL — реляционные базы данных, а также сложные текстовые или географические системы...
Здравствуйте, marat321, Вы писали:
M>Объектно-ориентированная, но сам движок сделан на реляционой =)
Вообще-то движок сделан на базе идеологии разреженных массивов или еще чего-то там в этом духе. Короче, точно не реляционный. SQL и реляционность эмулируются тачно так же как ООП. И не факт что SQL там лучше ООП.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, marat321, Вы писали:
M>Точно, мумпс — это иерархическая субд (такие были до реляционных)(одна из проблем — это для того, чтобы по порядку выбрать записи "таблицы", нужно было подниматься по ссылке к родителю, выбирать следующую ссылку, и по ней опускаться обратно). к ней прикручены интерфейсы sql и ооп.
А ты не путашь многомерные и иерерхические?
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Merle, Вы писали:
M>> С объектами же программисты привыкли делать всё, что им заблагорассудится. M>Угу, а знаешь почему? Потому что объект != данные. Объект — это поведение, данные же остаются неизменными, отсюда и возникает эта невиданная простота и легкость. Сегодня мы данные трактуем так — у нас один объект, завтра надо по другому — не вопрос, объект поменяли, данные остались. А как только мы пытаемся работать с данными как с объектами, то тут же вся гибкость идет лесом и на поверку оказывается, что реляционное представление данных, на данный момент, по гибкости еще никому превзойти не удалось, не смотря на то что из соображений производительности приходится в некоторой степени завязывать струтуру БД на семантику данных.
Честно говоря не вижу принципиальных препятствий для хранения объектов в БД в виде подобном тому, в каком они хранятся в оперативной памяти. Есть класс с описанием и методами, есть много его экземпляров с полями, со ссылками на другие объекты. В результате ВСЯ бизнес-логика сделана в методах этих классов, через них и работают пользователи БД.
Почему нельзя так?
M>> Для полного счастья программисту нужен ОДИН движок в котором он мог бы описать ВСЮ бизнес-логику программы и на любые извращённые запросы заказчика отвечать правкой пары строк в коде (может и на каком-нибудь OQL). M>Нет, в коде это еще не идеал. Заказчик должен кубики и стрелочки на экране передвигать.
Конечно! Заказчик рисует стрелочки и кубики, только в такой нотации, которая однозначно описывает модель на языке программиста. А программист на оновании этих рисунков вносит изменения в систему. Время, когда схема, нарисованная заказчиком, будет автоматически пониматься системой (без участия программиста), думаю настанет ещё не скоро.
Здравствуйте, Mazay, Вы писали:
M>Честно говоря не вижу принципиальных препятствий для хранения объектов в БД в виде подобном тому, в каком они хранятся в оперативной памяти.
Видишь суслика? Хранить объекты в БД в таком же виде как в памяти пытается уже ни одно поколение разработчиков, заметного прогресса пока не наблюдается...
M> Есть класс с описанием и методами, есть много его экземпляров с полями, со ссылками на другие объекты. В результате ВСЯ бизнес-логика сделана в методах этих классов, через них и работают пользователи БД. M>Почему нельзя так?
Очень просто. Бизнес-логика меняется, при том что данные остаются теми же. При изменении бизнес-логики, данные должны сохраниться, таким образом, в предложенной схеме, меняя объект, нам надо приложить бездну усилий, чтобы добиться неизменности и непротиворечивости данных. Реляционка же позволяет данные от логики отделить и менять одно независимо от другого с наименьшими дополнительными затратами. На практике оказывается намного дешевле потрахаться один раз при проектировании системы, чем трахаться каждый раз при изменении логики приложения и семантики данных.
Мухи и котлеты. Мухи летают, котлеты лежат на месте. Нельзя заставить котлеты летать, точнее можно, конечно, но плохо и не далеко, не надо пытаться облепить котлету мухами и думать, что она после этого полетит....
M>Конечно! Заказчик рисует стрелочки и кубики, только в такой нотации, которая однозначно описывает модель на языке программиста. А программист на оновании этих рисунков вносит изменения в систему.
Нафиг-нафиг. Во-првых я не встречал еще ни одной нотации, ктороая бы смогла однозначно описать модель да еще и на языке программиста, а во-вторых, я уж тем более не встречал ни одного заказчика четко понимающего что он хочет.
Поэтому если уж между заказчиком и системой стоит программист, то пусть общаются словами — оно существенно эффективнее.
M>Время, когда схема, нарисованная заказчиком, будет автоматически пониматься системой (без участия программиста), думаю настанет ещё не скоро.
Ну почему же... Уже в 2004 BizTalk-е была чудестная компонента (которую к слову, если я правильно помню, можно выдрать и вставить в свое приложение), которая позволяет прямо в студии, в картинках, описывать некие бизнес-правила, в частности ценообразование, и оные бизнесправила, без малейшего участия программиста вступают в силу, в указанные сроки.
Так что заказчицкое счастье в принципе возможно...
Mazay wrote:
> Честно говоря не вижу принципиальных препятствий для хранения объектов > в БД в виде подобном тому, в каком они хранятся в оперативной памяти. > Есть класс с описанием и методами, есть много его экземпляров с > полями, со ссылками на другие объекты. В результате *ВСЯ* > бизнес-логика сделана в методах этих классов, через них и работают > пользователи БД. Почему нельзя так?
Здравствуйте, Merle, Вы писали:
M>Здравствуйте, Mazay, Вы писали:
M>>Честно говоря не вижу принципиальных препятствий для хранения объектов в БД в виде подобном тому, в каком они хранятся в оперативной памяти. M>Видишь суслика? Хранить объекты в БД в таком же виде как в памяти пытается уже ни одно поколение разработчиков, заметного прогресса пока не наблюдается...
Жаль.
M>Очень просто. Бизнес-логика меняется, при том что данные остаются теми же. При изменении бизнес-логики, данные должны сохраниться, таким образом, в предложенной схеме, меняя объект, нам надо приложить бездну усилий, чтобы добиться неизменности и непротиворечивости данных. Реляционка же позволяет данные от логики отделить и менять одно независимо от другого с наименьшими дополнительными затратами. На практике оказывается намного дешевле потрахаться один раз при проектировании системы, чем трахаться каждый раз при изменении логики приложения и семантики данных.
По-моему реляционка просто забивает на бизнес-логику. Делай трехзвенку и реализуй логику на чём хочешь. Программисту конечно фиолетово, ему только заработок лишний от поддержки софта (вон как 1С этот процесс на конвейер поставила). Вот только тоскливо клепать в сущности похожие обработки, запросы и т.п. Хочется (в том числе и заказчику) автоматизации, чтоб заказчик сам рисовал схему процессов и пускал её в работу.
M>Мухи и котлеты.....
M>Нафиг-нафиг. Во-первых я не встречал еще ни одной нотации, ктороая бы смогла однозначно описать модель да еще и на языке программиста, а во-вторых, я уж тем более не встречал ни одного заказчика четко понимающего что он хочет. M>Поэтому если уж между заказчиком и системой стоит программист, то пусть общаются словами — оно существенно эффективнее.
Эффективнее если заказчик подвешен за крюк вниз головой (фигурально выражаясь). Беда конечно не в злобном заказчике, а в том, что разработчик и владелец процесса не имеют общего языка. Если заказчик сам будет рисовать схему, то он будет сам нести ответственность за косяки, которые сейчас возникают из-за его недоговорок. При такой схеме подобных проблем возникать вообще не должно.
M>>Время, когда схема, нарисованная заказчиком, будет автоматически пониматься системой (без участия программиста), думаю настанет ещё не скоро. M>Ну почему же... Уже в 2004 BizTalk-е была чудестная компонента (которую к слову, если я правильно помню, можно выдрать и вставить в свое приложение), которая позволяет прямо в студии, в картинках, описывать некие бизнес-правила, в частности ценообразование, и оные бизнесправила, без малейшего участия программиста вступают в силу, в указанные сроки. M>Так что заказчицкое счастье в принципе возможно...
Интересно. Посмотрю.
Здравствуйте, Mazay, Вы писали:
M>Жаль.
А чего жалеть, н а то объективные причины есть...
M>По-моему реляционка просто забивает на бизнес-логику.
Ты просто не умеешь ее готовить..
M> Хочется (в том числе и заказчику) автоматизации, чтоб заказчик сам рисовал схему процессов и пускал её в работу.
Хочется — это понятно, другое дело, что хранение данных в виде объектов этому хотению ни сколько не поможет, скорее наоборот.
M>Беда конечно не в злобном заказчике, а в том, что разработчик и владелец процесса не имеют общего языка. Если заказчик сам будет рисовать схему, то он будет сам нести ответственность за косяки, которые сейчас возникают из-за его недоговорок. При такой схеме подобных проблем возникать вообще не должно.
При такой схеме заказчик будет сам виноват только в том случае, если разработчика из схемы исключить полностью, в противном случае это не заказчик не смог объяснить, а разработчик не смог понять. Ну и плюс, лишний шанс допустить ошибку и что-то не так реализовать.
Здравствуйте, AndrewVK, Вы писали:
AVK>По семантике LINQ ближе к XPath, хотя синтаксически действительно похож на SQL.
Если более точно говорить, то к XQuery.
Здравствуйте, GlebZ, Вы писали:
AVK>>По семантике LINQ ближе к XPath, хотя синтаксически действительно похож на SQL. GZ>Если более точно говорить, то к XQuery.
Неа. XQuery в доках поминают исключительно ради красивого словца. А на самом деле чем XQuery кардинально отличается от XPath? Правильно, наличием конструкций для изменения данных. Можно в LINQ делать декларативное изменение данных?
Хотя конечно возможностей у LINQ поболее, чем у XPath.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, GlebZ, Вы писали:
AVK>>>По семантике LINQ ближе к XPath, хотя синтаксически действительно похож на SQL. GZ>>Если более точно говорить, то к XQuery.
AVK>Неа. XQuery в доках поминают исключительно ради красивого словца. А на самом деле чем XQuery кардинально отличается от XPath? Правильно, наличием конструкций для изменения данных. Можно в LINQ делать декларативное изменение данных?
Нету в XQuery — изменения данных. Оно может генерить данные в стиле XSL(или того же IEnumerator<>) но не изменять текущие.
Пример XQuery
for $item in doc("string.xml")//news_item
where contains(string($item/content), "Gorilla Corporation")
return
<item_summary>
{ concat($item/title,". ") }
{ concat($item/date,". ") }
{ string(($item//par)[1]) }
</item_summary>
AVK>Хотя конечно возможностей у LINQ поболее, чем у XPath.
А у XQuery еще больше.
Посмотри их Use Cases. По ним легко узнавать возможности языка. А язык действительно крутой получился.
Здравствуйте, Merle, Вы писали:
M>Угу, а знаешь почему? Потому что объект != данные. Объект — это поведение, данные же остаются неизменными, отсюда и возникает эта невиданная простота и легкость.
1. Не столь все однозначно. Данные — есть отражение предметной области. Собственно именно эта ошибка допущенная разработчиками SQL, что данные — есть данные а не отражение предметной области и привело к потере идентифицируемости данных и появления дубликатов.
2. Достаточно много структур, под которые реляционка мягко говоря не очень. Ну например, хранение исторических данных. Либо избыточность данных, либо пляски с бубном. Ну не надо мне хранить все прошлые данные, надо хранить только те которые изменились. VSS и SVN — тоже по сути хранят данные. Но реляционных решений, я что-то не видал. Или например иерархические справочники. Я понимаю что решений хоть отбавляй. Их действительно много и из разных красок. Но сама реляционка не поддерживает их.(Oracle с его time series и их иерарх. запросов оставим в стороне, в большинстве баз такого нет).
3. О том что при сращивании объектной модели и реляционной приходится плясать с бубном, уже наверно говорить не стоит. Способность реляционки трансформировать свою схему — конечно многого стоит. Но все равно, лучше бы и без этого.
Здравствуйте, GlebZ, Вы писали:
GZ>1. Не столь все однозначно.
Ясное дело, что нюансов много, но я ни где и не говорил, что реляционка идеальна.
GZ> Данные — есть отражение предметной области.
Скорее предметная область — отражение данных. Предметная область меняется, а сами данные — нет. Одни и те же данные могут выступать в разном качестве в разных предметных областях — это зависит от способа интерпретации, но ни как не от самих данных.
GZ>2. Достаточно много структур, под которые реляционка мягко говоря не очень. Ну например, хранение исторических данных.
С историческими данными проблем нет, если надо брать срезы, то лучше реляционки это мало кто сделает.
GZ> VSS и SVN — тоже по сути хранят данные. Но реляционных решений, я что-то не видал.
Плохо смотрел. Первое что приходит голову — новый MS-ный TFS, все хранилище в сиквеле, и документы, и VCS, и черт знает что еще...
GZ>Или например иерархические справочники. Я понимаю что решений хоть отбавляй. Их действительно много и из разных красок. Но сама реляционка не поддерживает их.(Oracle с его time series и их иерарх. запросов оставим в стороне, в большинстве баз такого нет).
Что значит не поддерживает? Во-первых с появлением Юкона все три основные СУБД имеют иерархические запросы, при этом у Оракла самый бедный вариант. А во-вторых такая поддержка по большему счету и не нужна, все и без нее реализуется....
Здравствуйте, Merle, Вы писали:
GZ>> Данные — есть отражение предметной области. M>Скорее предметная область — отражение данных. Предметная область меняется, а сами данные — нет. Одни и те же данные могут выступать в разном качестве в разных предметных областях — это зависит от способа интерпретации, но ни как не от самих данных.
Если две программы работают в одной предметной области, это не значит что это две предметной области и сущности с разными свойствами. Можешь привести пример?
GZ>>2. Достаточно много структур, под которые реляционка мягко говоря не очень. Ну например, хранение исторических данных. M>С историческими данными проблем нет, если надо брать срезы, то лучше реляционки это мало кто сделает.
Нет. Я не о срезе. Я об обеспечении среза. Допустим, у нас есть таблица которая отслеживает параметры приборов. Примерная данные {имя_прибора, напряжение, сила тока, сопротивление, время}. Изменяться одновременно могут только два параметра. Оставлять в одной таблице — избыточно. Разбивать по нескольким таблицам — еще избыточней. В ней нельзя отразить изменение только трех параметров.
GZ>> VSS и SVN — тоже по сути хранят данные. Но реляционных решений, я что-то не видал. M>Плохо смотрел. Первое что приходит голову — новый MS-ный TFS, все хранилище в сиквеле, и документы, и VCS, и черт знает что еще...
А TFS тут причем. Он разве хранит версии? Во вторых, для реляционки такие тексты — не более чем блобье(если конечно он не сохраняет их в xml, что ненамного лучше).
M>Что значит не поддерживает? Во-первых с появлением Юкона все три основные СУБД имеют иерархические запросы, при этом у Оракла самый бедный вариант. А во-вторых такая поддержка по большему счету и не нужна, все и без нее реализуется....
Посмотрел, реализацию. Такой же отстой что и в Oracle. Ну неэффективен доступ в parent child с рекурсивными запросами. На сайте была статейка и там были определены как оценивать эффективность иерархических запросов. Правильная статья, поскольку там есть очень важный и достаточно часто встречающийся запрос — взять всех потомков данной записи. Ручками такое делать эффективнее чем данными механизмами.
Здравствуйте, beroal, Вы писали:
B>Здравствуйте, Mazay, Вы писали: M>> С объектами же программисты привыкли делать всё, что им заблагорассудится. Можно задать самое извращённое поведение объекта, даже научить его понимать какой-нить язык описания ограничений или запросов. Для полного счастья программисту нужен ОДИН движок в котором он мог бы описать ВСЮ бизнес-логику программы и на любые извращённые запросы заказчика отвечать правкой пары строк в коде (может и на каком-нибудь OQL). Или просто обучить заказчика использованию BPEL (или что там будет). B>Если быть до конца честным, бледное подобие таких движков есть, а именно, я говорю о алгоритмических языках, встроенных в СУБД. Конечно, GUI на них писать пока ещё рано... Хотя есть PostgreSQL, где границы между своим и чужим ЯП практически стёрты.
Можно ли подробнее развить тему?
Здравствуйте, GlebZ, Вы писали:
GZ>Если две программы работают в одной предметной области, это не значит что это две предметной области и сущности с разными свойствами. Можешь привести пример?
Причем тут программы? Есть данные, например, плотность населения. Для экономиста и социолога семантика данных совершенно различна и объекты тоже разные, но цифра одна и та же.
GZ> Изменяться одновременно могут только два параметра. Оставлять в одной таблице — избыточно. Разбивать по нескольким таблицам — еще избыточней.
Уйти от избыточности в данной задаче проблем нет, другое дело что я не вижу причины уходить, ведь в конечном итоге важна эффективность и реляционка ее обеспечит наилучшим образом.
GZ>А TFS тут причем. Он разве хранит версии?
Ну здрасьте, хранит конечно. Там полноценный навороченый VCS, похлеще Perforce (которого имеет в дальних предках), и это не считая совершенно безумной иерархии документов с поддержкой той же истории. Да, и баг-трекинг туда же...
GZ> Во вторых, для реляционки такие тексты — не более чем блобье(если конечно он не сохраняет их в xml, что ненамного лучше).
Какая разница, блобы это или нет? Помимо самих текстов важны метаданные и тут реляционка себя проявляет в полный рост.
GZ>Посмотрел, реализацию. Такой же отстой что и в Oracle.
Значит плохо посмотрел.
GZ> Ну неэффективен доступ в parent child с рекурсивными запросами.
Шашечки или ехать? Если нужно удобство, то вот тебе простые запросы, к слову достаточно эффективные.
Если нужна действительно высокая производительность, то тогда делаем ручками в той же реляционке, потому как с объектами все равно получится хуже, если только хранение этих объектов специально под иерархию не заточено, да и то надо смотреть...
Здравствуйте, Merle, Вы писали:
M>Здравствуйте, GlebZ, Вы писали:
GZ>>Если две программы работают в одной предметной области, это не значит что это две предметной области и сущности с разными свойствами. Можешь привести пример? M>Причем тут программы? Есть данные, например, плотность населения. Для экономиста и социолога семантика данных совершенно различна и объекты тоже разные, но цифра одна и та же.
Я бы так не сказал. Если ты вложишь в данную сущность противоречивые свойства (а исходя из посыла, что это данные а не объект, то такое возможно), то кто-то из них работать не будет. Если у тебя есть счет, то независимо от того для чего ты его используешь, для анализа или проводок, для построения баланса или еще чего, он остается счетом. Ты можешь выцеплять различные его свойства, но они не должны противоречить ни друг другу, ни самому понятию счет. Поэтому отношение к данным, как просто к набору строк — неверно. За данными всегда кроется семантика их сущности.
GZ>> Изменяться одновременно могут только два параметра. Оставлять в одной таблице — избыточно. Разбивать по нескольким таблицам — еще избыточней. M>Уйти от избыточности в данной задаче проблем нет, другое дело что я не вижу причины уходить, ведь в конечном итоге важна эффективность и реляционка ее обеспечит наилучшим образом.
У тебя генерятся гигабайты информации. Притом избыточные гигабайты. И при этом ты говоришь об эффективности?
Избыточность информации может увеличить эффективность реляционной БД. Но переизбыток информации, уже нет. И даже индексы не спасут, потому как они сами по себе гигабайтные и их надо заполнять. И не все операции возможно делать именно через seek индекса.
GZ>>Посмотрел, реализацию. Такой же отстой что и в Oracle. M>Значит плохо посмотрел.
Уж как умею.
GZ>> Ну неэффективен доступ в parent child с рекурсивными запросами. M>Шашечки или ехать? Если нужно удобство, то вот тебе простые запросы, к слову достаточно эффективные. M>Если нужна действительно высокая производительность, то тогда делаем ручками в той же реляционке, потому как с объектами все равно получится хуже, если только хранение этих объектов специально под иерархию не заточено, да и то надо смотреть...
ЭЭЭЭ. Реляционка предоставляет очень быструю реализацию реляционных структур. При разработке, было все положено для реализации максимально быстрой БД. И отношение к БД то, что ее основное качество быстрота, сохранилось и сейчас. И начиная с времен SystemR она оценивалась прежде всего с этой стороны. Так почему сейчас нас накормили полумерами?
Здравствуйте, GlebZ, Вы писали:
GZ>Если ты вложишь в данную сущность противоречивые свойства (а исходя из посыла, что это данные а не объект, то такое возможно), то кто-то из них работать не будет.
Я не могу заложить в сущность противоречивые свойства так как сущности у меня пока нет. У меня есть данные, а сущность — это вопрос интерпретации этих данных.
GZ>Если у тебя есть счет, то независимо от того для чего ты его используешь, для анализа или проводок, для построения баланса или еще чего, он остается счетом.
У меня нет счета. У меня есть данные, вот если я на их основе создам объект "счет", вот тогда я буду работать с ними как со счетом, но это уже другая исторя. Если же у меня изначально не данные, а именно "счет", то очень велик шанс, что объект "счет" окажется не достаточно универсальным, чтобы удовлетворить все запросы к данным которые он в себе содержит и тогда количество геморроя на строчку кода по извлечению этих данных превзойдет самые смелые ожидания. А вот если у нас данные это просто данные то такая проблема вообще не стоит, на этом реляционка и держится. Потому что даже сейчас используются те самые цифры, которые вбивались в реляционные БД более 20 лет назад. И базы уже другие, и железо другое, и анализируют эти цифры совсем другие программы и совсем по другим алгоритмам, только цифры остались прежними, и получилось так именно потому, что реляционная модель, работает с данными, а не с их интерпретацией.
GZ> Ты можешь выцеплять различные его свойства, но они не должны противоречить ни друг другу, ни самому понятию счет.
Нет такой проблемы. Точнее это проблема непротиворечивого представления объекта, и она вылезет в любом случае.
GZ> Поэтому отношение к данным, как просто к набору строк — неверно. За данными всегда кроется семантика их сущности.
Проблема в том, что семантика меняется, а цифры остаются те же. И надо использовать те же цифры, но по другому. А если завязываться на семантику, то использовать те же цифры будет очень проблематично.
Поэтому к данным надо относиться именно как к данным, завязываясь (на низком уровне) на их семантику только в самом крайнем случае.
GZ>У тебя генерятся гигабайты информации. Притом избыточные гигабайты. И при этом ты говоришь об эффективности?
Именно. Гигабайты по нонешним меркам — не объем, да и уйти от избыточности не сложно.
GZ> Так почему сейчас нас накормили полумерами?
Можешь предложить вариант лучше?
Здравствуйте, Merle, Вы писали:
M>Нет такой проблемы. Точнее это проблема непротиворечивого представления объекта, и она вылезет в любом случае. M>Проблема в том, что семантика меняется, а цифры остаются те же. И надо использовать те же цифры, но по другому. А если завязываться на семантику, то использовать те же цифры будет очень проблематично.
Именно. Проблемы непротиворечивого представления объекта (или данных все равно). Я согласен с Дейтом что разработчиков SQL увело в сторону, и они забыли именно о непротиворечивом представлении объекта, и ослабили условие на primary key. У них повело не просто систему отображения данных на сущности, у них повело даже сам механизм выполнения SQL запросов.
M>Поэтому к данным надо относиться именно как к данным, завязываясь (на низком уровне) на их семантику только в самом крайнем случае.
Констраинт — это семантика. Введение доменов — также семантика.
Я никогда не оспаривал вопрос в том, что в БД не должно отражаться поведение объектов, но семантика данных (а это свойства сущности) все таки есть.
GZ>>У тебя генерятся гигабайты информации. Притом избыточные гигабайты. И при этом ты говоришь об эффективности? M>Именно. Гигабайты по нонешним меркам — не объем, да и уйти от избыточности не сложно.
Да нет. Уйти — танца с бубном не избежать. Либо отойти от реляционки в чего-нибудь типа Data Mining(Data Warehouse) вместе с OLAP.
GZ>> Так почему сейчас нас накормили полумерами? M>Можешь предложить вариант лучше?
Для реляционки? Конечно да. Не секрет что большинство современных БД строку на физ. уровне хранят как список полей. Для Time Series — это в самый раз. Хранить только те данные которые нужны. В заголовке таблицы — хранить ссылки на актуальные на последний момент записи для каждого столбца. Это некоторый отход от реляционной модели, но проблем несовместимости не вижу.
Что касается иерархии, то хранить именно иерархию. И необязательно в таблице, и необязательно явно. Так чтобы можно было делать нерекурсивные запросы. Это потребует некоторых ресурсов от БД, но и выйгрыш будет значительный.
Здравствуйте, GlebZ, Вы писали:
GZ>Я согласен с Дейтом что разработчиков SQL увело в сторону, и они забыли именно о непротиворечивом представлении объекта, и ослабили условие на primary key. У них повело не просто систему отображения данных на сущности, у них повело даже сам механизм выполнения SQL запросов.
Их конечно увело в сторону, но вовсе не по этому, а скорее даже наоборот.
GZ>Да нет. Уйти — танца с бубном не избежать. Либо отойти от реляционки в чего-нибудь типа Data Mining(Data Warehouse) вместе с OLAP.
Да никаких танцев, не больше чем обычно, а OLAP таже реляционка только в профиль...
M>>Можешь предложить вариант лучше? GZ>Для реляционки?
Чем реляционка.
GZ>Конечно да. Не секрет что большинство современных БД строку на физ. уровне хранят как список полей.
Как запись с заголовком, сплошным блоком.
GZ> Для Time Series — это в самый раз. Хранить только те данные которые нужны. В заголовке таблицы — хранить ссылки на актуальные на последний момент записи для каждого столбца.
Зачем??
GZ> Это некоторый отход от реляционной модели, но проблем несовместимости не вижу.
Пересть реляционной модели в ее универсальности. Было много попыток как-то чуть-чуть ее переделать под некоторые особенные классы задачь, ни одна из них успехом не увенчалась.
GZ>Что касается иерархии, то хранить именно иерархию. И необязательно в таблице, и необязательно явно. Так чтобы можно было делать нерекурсивные запросы. Это потребует некоторых ресурсов от БД, но и выйгрыш будет значительный.
Во-первых выигрыш если и будет, то не значительный, а во-вторых, опять смотри предыдущий абзац про универсальность.
Ну не нужны, как оказалось на практике, только иерархические запросы. Все остальное проседает на столько что пользоваться этим невозможно.
GlebZ wrote:
> VSS и SVN — тоже по сути хранят данные. Но реляционных решений, я > что-то не видал.
Кстати, до недавнего времени SVN использовал для хранения данных
реляционную BerkeleyDB. У них даже схема данных была нарисована в доке.
Сейчас они переехали на свой велосипед, жестко заточеный под их схему.
> Или например иерархические справочники. Я понимаю что решений хоть > отбавляй. Их действительно много и из разных красок. Но сама > реляционка не поддерживает их.
Поддерживает, например можно представить иерархию таким образом:
1. Корневой узел задается числом 1/2 (т.е. 0.5).
2. Его левый ребенок задается числом 1/4.
3. Правый ребенок — числом 3/4.
4. Левый ребенок левого ребенка корневого узла будет задаваться числом 1/8.
И так далее рекурсивно.
При такой схеме запросы "найти всех (левых/правых) детей узла X" будут
выражаться в виде обычных сравнений. А если еще скомбинировать это с
классической схемой задания иерархии с помощью обратных указателей на
родителя — то вообще все прекрасно получается.
> 3. О том что при сращивании объектной модели и реляционной приходится > плясать с бубном, уже наверно говорить не стоит.
Стоит. Так как хорошие нормализованые модели БД прекрасно ложаться на
объекты.
Здравствуйте, ironwit, Вы писали: B>>Если быть до конца честным, бледное подобие таких движков есть, а именно, я говорю о алгоритмических языках, встроенных в СУБД. Конечно, GUI на них писать пока ещё рано... Хотя есть PostgreSQL, где границы между своим и чужим ЯП практически стёрты. I>Можно ли подробнее развить тему?
Процедуры/функции (триггера в т.ч.) могут быть написаны на C или на любом другом языке, если интерпретатор для него подключен к серверу.
PostgreSQL allows user-defined functions to be written in other languages besides SQL and C. These other languages are generically called procedural languages (PLs). For a function written in a procedural language, the database server has no built-in knowledge about how to interpret the function's source text. Instead, the task is passed to a special handler that knows the details of the language. The handler could either do all the work of parsing, syntax analysis, execution, etc. itself, or it could serve as "glue" between PostgreSQL and an existing implementation of a programming language.
...
There are currently four procedural languages available in the standard PostgreSQL distribution: PL/pgSQL (Chapter 35), PL/Tcl (Chapter 36), PL/Perl (Chapter 37), and PL/Python (Chapter 38).
Здравствуйте, Merle, Вы писали:
GZ>> Это некоторый отход от реляционной модели, но проблем несовместимости не вижу. M>Пересть реляционной модели в ее универсальности. Было много попыток как-то чуть-чуть ее переделать под некоторые особенные классы задачь, ни одна из них успехом не увенчалась.
Это еще почему? Как-то решили сделать протокол, чтобы можно было распространять данные без клиента БД. Ну и придумали XML. Приделали так, сказать собачке хвост. А потом оказалось. что xml несколько больше чем протокол передачи данных. И не очень-то натягивалось на реляционку. До этого, реляционщики закрывали глаза на слабоструктурированные данные. Ну храните в блобье, пользуйте вручную, а мы о них не знаем, и ведать не ведаем. Не наши проблемы. А тут, приспичило. Ну очень хочется, и юзверя требуют. Вот и начали приделывать к реляционке слабоструктурированный xml. Хвост начал махать собачкой.
Здравствуйте, Merle, Вы писали:
GZ>>Да нет. Уйти — танца с бубном не избежать. Либо отойти от реляционки в чего-нибудь типа Data Mining(Data Warehouse) вместе с OLAP. M>Да никаких танцев, не больше чем обычно, а OLAP таже реляционка только в профиль...
Из одинакового — только автор, и то что некоторые версии OLAP может использовать реляционку для хранения своих данных.
M>>>Можешь предложить вариант лучше? GZ>>Для реляционки? M>Чем реляционка.
Сервер БД который встроен в сервер приложений. Однозначно должен быть OODB(который не плодит модели). Должен держать возможность хранения слабоструктурированных данных. Должен быть быстрый как декларативный так и навигационный доступ. Все встроенные сервера приложений в реляционку слишком ограничены возможностями БД(я сужу по нетовскому).
GZ>>Конечно да. Не секрет что большинство современных БД строку на физ. уровне хранят как список полей. M>Как запись с заголовком, сплошным блоком.
Без разницы. Главное что структура переменной длины.
GZ>> Для Time Series — это в самый раз. Хранить только те данные которые нужны. В заголовке таблицы — хранить ссылки на актуальные на последний момент записи для каждого столбца. M>Зачем??
Получение последних данных — наиболее частая операция.
GZ>> Это некоторый отход от реляционной модели, но проблем несовместимости не вижу. M>Пересть реляционной модели в ее универсальности. Было много попыток как-то чуть-чуть ее переделать под некоторые особенные классы задачь, ни одна из них успехом не увенчалась.
Это уже в соседнем сообщении.
M>Ну не нужны, как оказалось на практике, только иерархические запросы. Все остальное проседает на столько что пользоваться этим невозможно.
Никто и не говорил о только иерархических запросах. И вообще я не говорил о выходе за пределы реляционных запросов. Разговор о том, что при рекурсивных запросах на большом количестве данных, БД проседать будет. Если хранить иерархию, и нерекурсивно получать полные пути к элементам, то проседать не будет. Только всего-лишь и разница. А хранение иерархии — в принципе можно и реляционно организовать(правда может некоторая управляемая рекурсия для очень глубоких иерархий получится). А если к этому подключить аппарат оптимизации запросов, то совсем хорошо будет.
Здравствуйте, dmz, Вы писали:
dmz>Н-да? Можно примеры реализации каких-нибудь больших систем на основе OODBMS ? Что-нибудь типа биллинга, dmz>еще-то нибудь? Вот у нас, например, тут на оракле стоит препейдная система (ну, биллинг, короче — что бы не заморачиваться) dmz>- там есть таблица с количеством записей — сотни миллионов. Работает в почти-рилтайме, жестко соблюдается максимальное время dmz>ответа для некоторых операций (менее 5 секунд). Что-нибудь подобное можно организовать на OODBMS?
Да легко. Даже были примеры. Для операционных задач со сложной структурой OODBMS быстрее справляется чем RDB. Поищи по форуму, там были ссылки. В том числе благодаря навигационному доступу.
Да и к тому же, существует миф что ООDBMS — отрицает реляционное хранение. В большинстве сегодняшних продуктов это не так. ООDB — использует на физике именно реляционное хранение. И оптимизация запросов именно по Киму + дополнительные фичи.
Здравствуйте, GlebZ, Вы писали:
GZ>Это еще почему?
По совокупности обстоятельств.
GZ> Как-то решили сделать протокол, чтобы можно было распространять данные без клиента БД. Ну и придумали XML.
При чем тут XML?
XML сама по себе конструкция достаточно универсальная, но для хранения больших объемов данных с возможностью произвольной выборки — малопригодная.
И что самое забавное, для реализации XQuery документ XML раскладывается внизу все равно на реляционное представление, так что не угадал ты с примером...
GZ>Сервер БД который встроен в сервер приложений. Однозначно должен быть OODB(который не плодит модели). Должен держать возможность хранения слабоструктурированных данных. Должен быть быстрый как декларативный так и навигационный доступ. Все встроенные сервера приложений в реляционку слишком ограничены возможностями БД(я сужу по нетовскому).
Не, я тоже конечно могу идеальную сферическую систему в вакууме придумать, но толку-то. Никогда не задавался вопросом, почему до сих пор ничего подобного не сделали?
Сейчас тенденция скорее сервера приложений в БД встраивать, причем в реляционные, а не наоборот, и это не с проста.
GZ>Получение последних данных — наиболее частая операция.
Думаешь хранение ссылок ее ускорит? Это тот же индекс, только в профиль, так почему бы обычный индекс не задействовать.. Не надо обходные маневры на ровном месте придумывать.
GZ>Никто и не говорил о только иерархических запросах.
Тогда в чем проблема?
Вывод: Задачи с иерархией не проблема для реляционных БД.
Здравствуйте, Merle, Вы писали:
M>XML сама по себе конструкция достаточно универсальная, но для хранения больших объемов данных с возможностью произвольной выборки — малопригодная.
Поговорим о Sedna XML или еще какой-нибудь XML БД? Ты им это не рассказывал? А там между прочим нехилые люди сидят. Теоретики БД.
M>И что самое забавное, для реализации XQuery документ XML раскладывается внизу все равно на реляционное представление, так что не угадал ты с примером...
Не подменяй понятия. Если там используется реляционное исчисление или похожее, это не значит что это именно реляционка. Алгебру моноидов тоже можно назвать продвинутым реляционным исчислением. Только почему-то не называют. Не удивлюсь если MSSQL реализовал XQuery запросы только в рамках своего аппарата. Но вообще-то, для построения эффективного вычисления XQuery запросов нужны дополнительные команды. Ну хреново, когда вложенный объект, которые безусловно можно математически описать реляционным join, получают через join. Неэффективно.
Вообще, уже лет пять большая часть прогрессивного сообщество которое занимается развитием БД, работает именно над запросами к XML. И те работы которые я видел, уже давно вышли за рамки стандартного реляционного аппарата современных реляционок. Развитие в рамках реляционной модели данных уже достигло максимума. Быстрее этого уже не будет(хотя есть еще некоторые недоработки в области индексов). Для дальнейшего развития давно уже ослабили требования реляционнок на структурированность данных.
Здравствуйте, Merle, Вы писали:
M>Сейчас тенденция скорее сервера приложений в БД встраивать, причем в реляционные, а не наоборот, и это не с проста.
Неужели денег хотят?
M>Тогда в чем проблема? M>Вывод: Задачи с иерархией не проблема для реляционных БД.
Ага, а проблема архитектора. И притом настолько частая, что возникает в любом мало-мальски большом приложении.
Здравствуйте, GlebZ, Вы писали:
GZ>Поговорим о Sedna XML или еще какой-нибудь XML БД? Ты им это не рассказывал? А там между прочим нехилые люди сидят. Теоретики БД.
Ага и где они сидят? Хоть одно серьезное коммерческое приложение на XML базе в качестве основного хранилища есть?
GZ>Не подменяй понятия.
Не подменяю.
GZ> Если там используется реляционное исчисление или похожее, это не значит что это именно реляционка.
А что же это значит?
GZ> Не удивлюсь если MSSQL реализовал XQuery запросы только в рамках своего аппарата. Но вообще-то, для построения эффективного вычисления XQuery запросов нужны дополнительные команды.
Не в командах дело, а в представлении. Для хранения внутри XML раскладывается в структуру напоминающую обычные реляционные таблицы.
GZ>Ну хреново, когда вложенный объект, которые безусловно можно математически описать реляционным join, получают через join. Неэффективно.
Это кто сказал, что не эффективно? И дело не в описании, а в физической операции. Так вот оказалось, что выгоднее всего для иерархических операций, таки свести их к реляционным и так с ними и работать.
GZ>Вообще, уже лет пять большая часть прогрессивного сообщество которое занимается развитием БД, работает именно над запросами к XML. И те работы которые я видел, уже давно вышли за рамки стандартного реляционного аппарата современных реляционок.
А ты хорошо себе представляешь аппарат современных реляционок? Все что я видел из работ прогрессивного человества сводится к попыткам свести XML к плоским таблицам для большей эффективности.
GZ> Развитие в рамках реляционной модели данных уже достигло максимума. Быстрее этого уже не будет(хотя есть еще некоторые недоработки в области индексов).
Только вот превзойти эту скорость, на широком классе задачь, пока что не получалось ни у кого...
GZ>Для дальнейшего развития давно уже ослабили требования реляционнок на структурированность данных.
Для дальнейшего развития куда?
Здравствуйте, Merle, Вы писали:
M>Здравствуйте, GlebZ, Вы писали:
GZ>>Поговорим о Sedna XML или еще какой-нибудь XML БД? Ты им это не рассказывал? А там между прочим нехилые люди сидят. Теоретики БД. M>Ага и где они сидят? Хоть одно серьезное коммерческое приложение на XML базе в качестве основного хранилища есть?
Во первых, слишком маленький возраст. Для справки, проект System R — разрабатывался, по моему, в течении 8 лет. С 1972-по 1980. Работа Кодда — 68-69гг. Коренная доработка проводилась еще в течении 80'ых(логическая оптимизация, семантическая оптимизация, System R*). Стало более менее мейнстримом в начале 90-ых.
Во вторых, самих баз до фигищи, чуть ли не в каждом продвинутом университете. А пересчитай на пальцах серьезные коммерческие ДБ и сколько лет было развития до того как они стали серьезными.
GZ>> Если там используется реляционное исчисление или похожее, это не значит что это именно реляционка. M>А что же это значит?
А то что подмени термины на отношения и кортежи, и многие формулы будут эквивалентные. Законы физики они и в Африке действуют.
GZ>> Не удивлюсь если MSSQL реализовал XQuery запросы только в рамках своего аппарата. Но вообще-то, для построения эффективного вычисления XQuery запросов нужны дополнительные команды. M>Не в командах дело, а в представлении. Для хранения внутри XML раскладывается в структуру напоминающую обычные реляционные таблицы.
Ну да, именно напоминающую. Реляционная модель — строгая модель как и любая другая математическая модель. Все что не входит в ее алфавит, уже не входит в реляционную модель. А алфавит небольшой — аттрибут, кортеж, отношение, да может еще что-то придумать можно(сходу не скажу). И достаточно небольшой набор операций. Насколько я знаю, термина связи как таковой там нет. Там только описание трансформаций модели. Там не было в алфавите вложенных таблиц. Отношения все равноправны. Там много чего не было, что сейчас используется.
Насчет альтернативных команд, как тебе такое:
unnest, returns the collection of all pairs (x, y) for each x in X and for each y in x.path that satisfy the predicate p(x, y).
Это базовая алгебра моноидов из Фегараса.
GZ>>Ну хреново, когда вложенный объект, которые безусловно можно математически описать реляционным join, получают через join. Неэффективно. M>Это кто сказал, что не эффективно? И дело не в описании, а в физической операции. Так вот оказалось, что выгоднее всего для иерархических операций, таки свести их к реляционным и так с ними и работать.
Это конкретный случай. Я его специально попытался впихнуть реляционную модель, для того чтобы показать что никаких проблем нет. Ну почти проблем нет.
GZ>>Вообще, уже лет пять большая часть прогрессивного сообщество которое занимается развитием БД, работает именно над запросами к XML. И те работы которые я видел, уже давно вышли за рамки стандартного реляционного аппарата современных реляционок. M>А ты хорошо себе представляешь аппарат современных реляционок? Все что я видел из работ прогрессивного человества сводится к попыткам свести XML к плоским таблицам для большей эффективности.
И да и нет. Плоские таблицы удобны потому как хранение у нас двухмерное. Но реляционная алгебра, как и другая алгебра состоит из четырех частей: алфавит, утверждения, аксиомы, правила вывода. Модель абстрактная, описывает законы а не реализацию. Реализацию потом додумывают. Так вот, вводим термин путь, и мы уже за пределами модели. Это уже другая алгебра. Но она не противоречит предыдущей алгебре.
Если говорить об алгебре Кодда, то она была изменена. Туда были добавлены дополнительные правила вывода(полусоединение, антисоединения и outerjoin и по моему G-Agg). Аксиомы и тем более алфавит были нетронуты. Поэтому это как была реляционка, так ею и осталась, иногда правда называют — расширенная реляционная алгебра.
Это про теорию. А про реализацию могу еще намекнуть, каким образом слабоструктурированный xml будет у тебя индексироваться?
GZ>> Развитие в рамках реляционной модели данных уже достигло максимума. Быстрее этого уже не будет(хотя есть еще некоторые недоработки в области индексов). M>Только вот превзойти эту скорость, на широком классе задачь, пока что не получалось ни у кого...
И не превзойдут. Пока не надо будет выходить за пределы модели, не превзойдут. Ну а поскольку большинство бизнес-задач прекрасно описываются в терминах реляционки, то революция откладывается.
GZ>>Для дальнейшего развития давно уже ослабили требования реляционнок на структурированность данных. M>Для дальнейшего развития куда?
Вперед!!! К заоблачным высотам. К молочным берегам, и кисельным рекам. Ты же не думаешь, что на реляционных базах все остановилось. Сам говорил что не идеально.
Здравствуйте, GlebZ, Вы писали:
GZ>Во первых, слишком маленький возраст.
Более чем.
GZ> Для справки, проект System R — разрабатывался, по моему, в течении 8 лет. С 1972-по 1980. Работа Кодда — 68-69гг. Коренная доработка проводилась еще в течении 80'ых(логическая оптимизация, семантическая оптимизация, System R*). Стало более менее мейнстримом в начале 90-ых.
Для справки. Возраст иерархических БД гораздо больше реляционных, объектные БД пытаются разработать уже лет пятнадцать, XML-ные лет 5-6. Оракл выпустил первую крайне успешную коммерческую реализацию реляционки года за три-четыре, раньше чем IBM очнулась и начала что-то выпускать на основе System R.
Так что времени было более чем достаточно.
GZ> А пересчитай на пальцах серьезные коммерческие ДБ и сколько лет было развития до того как они стали серьезными.
Оракл стал серьезным спустя два-три года после своего появления, при этом это была в принципе первая коммерческая СУБД.
GZ>А то что подмени термины на отношения и кортежи, и многие формулы будут эквивалентные. Законы физики они и в Африке действуют.
Отсюда делаем вывод, что раз действуют законы реляционки, то это реляционка.
GZ>Ну да, именно напоминающую.
"Человек похожий на генерального прокурора ..."
GZ>Реляционная модель — строгая модель как и любая другая математическая модель. Все что не входит в ее алфавит, уже не входит в реляционную модель. А алфавит небольшой — аттрибут, кортеж, отношение, да может еще что-то придумать можно(сходу не скажу). И достаточно небольшой набор операций. GZ> Насколько я знаю, термина связи как таковой там нет. Там только описание трансформаций модели. Там не было в алфавите вложенных таблиц. Отношения все равноправны. Там много чего не было, что сейчас используется.
Отлично. Так вся структура к которой сводится XML при хранении, чудным образом описывается этим скудным аппаратом. (К слову он не такой уж скудный, там есть много того что сейчас не используется, но не о том речь, суть-то сохранена)
Все что сейчас хоть как-то имеет широкое практическое применение в области БД, построено на реляционной модели, вне зависимости от ее строгости и расширенности.
GZ>Насчет альтернативных команд, как тебе такое:
А при чем тут команды? Хоть горшком назови... Не смущает, что в третьем шарпе синтаксис очень сильно совпадающий с SQL-м работает, тем не менее, по иерархическим запросам?
GZ>Я его специально попытался впихнуть реляционную модель, для того чтобы показать что никаких проблем нет. Ну почти проблем нет.
Ну вот и договорились..
GZ>И да и нет. Плоские таблицы удобны потому как хранение у нас двухмерное. Но реляционная алгебра, как и другая алгебра состоит из четырех частей: алфавит, утверждения, аксиомы, правила вывода. Модель абстрактная, описывает законы а не реализацию. Реализацию потом додумывают. Так вот, вводим термин путь, и мы уже за пределами модели.
Почему это за пределами? Как только мы описываем путь в терминах существующей модели, исчезает необходимость за пределы оной модели выходить..
GZ>Это про теорию. А про реализацию могу еще намекнуть, каким образом слабоструктурированный xml будет у тебя индексироваться?
Ты лучше намекни откуда ты взял, что XML слабоструктурированный... Он на самом деле существенно более структурированный нежели реляционная модель. А индексироваться он будет очень просто, как только мы сведем его к реляционке проблем не останется. Собственно так и поступают.
Здравствуйте, Mazay, Вы писали:
M>Честно говоря не вижу принципиальных препятствий для хранения объектов в БД в виде подобном тому, в каком они хранятся в оперативной памяти.
Если оставить СКВВ в покое, то как будет происходить процесс изменения структуры объектов. Например, добавили мы, удалили или изменилии тип поля в объекте. Что будет просиходить при чтении объекта старой структуры? Куда денутся убитые поля, откуда появятся новые и кто будет заниматься конвертацией изменённых?
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, GlebZ, Вы писали:
GZ>VSS и SVN — тоже по сути хранят данные. Но реляционных решений, я что-то не видал.
Source Gear Vault — отличается умом и сообразительностью, и на порядок более высокой производительностью чем вышеобозначенные (особенно первый) товарищи.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, beroal, Вы писали:
B>Здравствуйте, ironwit, Вы писали: B>>>Если быть до конца честным, бледное подобие таких движков есть, а именно, я говорю о алгоритмических языках, встроенных в СУБД. Конечно, GUI на них писать пока ещё рано... Хотя есть PostgreSQL, где границы между своим и чужим ЯП практически стёрты. I>>Можно ли подробнее развить тему? B>Процедуры/функции (триггера в т.ч.) могут быть написаны на C или на любом другом языке, если интерпретатор для него подключен к серверу.
Здравствуйте, 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>эффективно представить дерево в РБД — я уже привел.
Эээ. Связь может быть между таблицами, а может быть между строками. В данном случае имеется ввиду именно связь кортежей в отношении.
Здравствуйте, GlebZ, Вы писали:
GZ>Ага. У меня сегодня день рождения моего кровопийцы. Два года. Поэтому воинственно радуюсь жизни.
Ну поздравляю !
GZ>Повторяю. Результаты то есть. Но для большинства хватает реляционки. О чем и разговор.
Это значит результатов нет..
GZ>А здесь здесь GZ>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.
Там же...
A primary XML index on an XML column creates a B+tree index on all tags, values, and paths of the XML instances in the column. It provides efficient evaluation of queries on XML data, and reassembly of the XML result from the B+tree while preserving document order and document structure.
GZ>Отмазки? Ну валяй источниками. Интересно.
Тех же келковских статей по работе с иерархией всему инету навалом...
Здравствуйте, Merle, Вы писали:
M>Здравствуйте, GlebZ, Вы писали:
GZ>>Ага. У меня сегодня день рождения моего кровопийцы. Два года. Поэтому воинственно радуюсь жизни. M>Ну поздравляю !
Спасибо.
GZ>>Повторяю. Результаты то есть. Но для большинства хватает реляционки. О чем и разговор. M>Это значит результатов нет..
Нет, это просто нужно спрашивать у версантовцев. Они это красочно обрисуют.
GZ>>А здесь здесь GZ>>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. M>Там же... M>A primary XML index on an XML column creates a B+tree index on all tags, values, and paths of the XML instances in the column. It provides efficient evaluation of queries on XML data, and reassembly of the XML result from the B+tree while preserving document order and document structure.
Ну да, а ведь можно его и не создавать.
Вообще, занятная статья оказалась. Не сразу ее заметил.
И кстати, очень понравилось индексация путей. Очень реляционно.
GZ>>Отмазки? Ну валяй источниками. Интересно. M>Тех же келковских статей по работе с иерархией всему инету навалом...
Там вопрос не в иерархии. Человек хочет автоматическую версионификацию схемы данных.
Здравствуйте, GlebZ, Вы писали:
GZ>Спасибо.
Да пожалуйста..
GZ>Нет, это просто нужно спрашивать у версантовцев. Они это красочно обрисуют.
Я вот этого вот красочного рисования от Microsoft-а полной ложкой... Только с ушей и стряхивай...
GZ>Ну да, а ведь можно его и не создавать.
Хозяин барин... Там BLOB — это похоже обманка, чтобы всегда можно было сделать cast ... as xml
GZ>И кстати, очень понравилось индексация путей. Очень реляционно.
Вот описание алгоритма: http://www.cs.umb.edu/~poneil/ordpath.pdf
На самом деле в MS-ных конференциях была очень интересная дискуссия по этому поводу, но к сожалению NDA. Вот коротенькая цитата "XQuery uses the relational query engine for the most part. Optimization works similarly modulo the query language itself"
Ну и интервью с дядькой, который все это дело в юконе реализовывал, там и про хитрые индексы quad trees, R-tree, и прочие надругательства и почему B-tree, но все это аудио. http://www.sqlsummit.com/People/MRys.htm
GZ> Человек хочет автоматическую версионификацию схемы данных.
Ну сам же понимаешь, что без конкретики это не серьезно... )
), где велась работа с разнообразными, но _родственными_ объектами. Или объектами, различающимися в одном свойстве, но от этого свойства изменялась логика работы приложения.
Или придумали? *с надеждой*
Если нам не помогут, то мы тоже никого не пощадим.
1.1.4 stable rev. 510
Мы уже победили, просто это еще не так заметно...
Оператор пыталась заставить систему (Amadeus) выдать остановку в Осло меньше, чем 24 часа 
Не помню, чем все это закончилось. По-моему, 8-часовой остановкой в Вене.
