Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 [4] 5   вперед  Ctrl      все
 Re: ОРБД. сравнение объектных расширений реляционных СУБД.  [new]
mir
Member

Откуда: Томск
Сообщений: 1027
okdoky
Разговор глухих и слепых. Сколько ни показывал и ни выяснял, все напрасно. И JOIN демонстрировал в каком-то топике и на счет целостности говорил. Понятно только то, что на SQL и в виде таблицы? Зигзаг оперирует не только таблицами, но и деревьями. У Zigzag-таблиц записи автоматически упорядочиваются по первому ключевому полю. Вершины на всех уровнях дерева также имеют упорядоченность. Например, на SQL есть таблица A; B; C; D. Я могу сразу создать иерархическую структуру B:A:C(A,B,C,D). Можно опять же в цикле для произвольной сортировки создавать промежуточные таблицы, у которых будет в качестве ключевого поля конкатенация произвольных полей. Распечатывать конечно можно только определенные колонки таблицы. Есть возможность обратного прохода опять же в цикле используя методы last() и back() для обратного упорядочивания.
Короче, что на SQL делается строчечкой вроде ORDER BY Col1 DESC, Col3 ASC, Col5 DESC, на ZZ потребует охеренных усилий. Ладно, тут за это вас и так распяли ржавыми гвоздями, мне интересно другое. Во-первых, про JOIN. Сделайте одолжение, дайте либо ссылочку, либо повторите для нас убогих. Раз уж в этой теме мы начали все претензии к ZZ систематизировать. То же и про целостность. В этой теме вы по поводу целостности несли ахинею, а когда я откомментировал и попросил разъяснений, просто перестали про это отвечать (любимый прием). Тоже прошу, дайте либо ссылочку, либо повторите где и что в другом топике вы рассказали про целостность в ZZ.
13 апр 06, 07:59    [2556279]     Ответить | Цитировать Сообщить модератору
 Re: ОРБД. сравнение объектных расширений реляционных СУБД.  [new]
okdoky
Member

Откуда:
Сообщений: 349
Nikolay Kulikov
Сравни свою процедуру которую придется переделывать достаточно часто с запросом

Количество сумма продаж за 1 неделю 2 квартала, продуктов в категории ZZZ
в магазинах находящихся в городах с количеством жителей от 100.000 до 300.000

select sh.shopname,pr.productname,Sum(sa.USD),count(sa.USD) from SALES
from shop sh ,sales sa, product pr
where
sh.shopid=sa.shopid and
pr.productid=psa.productid and
pr.category='ZZZ'
sh.citizens# between 100000 and 300000
group by sh.shop,pr.product


Самое удивитиельное, все параметры для группировки можно добавлять и удалять динамически, без написания нового класса на каждый запрос :)

И что мы будем делать если условий будет не 4 как я указал, а 20 в твоем zig-zage

Чем твои промежуточные таблицы отличаются от временных таблиц или Common Table Expression в SQL??? Там тоже иерархии можно делать. Ты из SQL знаешь только select * from и утверждаешь что какие-то возможности в zig-zag. Лучше. Лучше не увидел увидел короче и непонятней...
Почему Вы решили, что нужно писать новый класс под каждый запрос, а не сделать один универсальный? При этом в качестве параметров можно передавать массивы, даже строки со специальными разделителями? Перебираемые записи можно определить заранее
"$x = проданный товар:(категория:ZZZ,
магазин:(город:(количество жит*:100.000^300.000)),
дата:2005-04-01^2005-04-07);"
Кстати, чем больше условий в запросе, тем больше преимущества будет у Zigzag по быстродействию. Это мы уже проверяли в сравнении с Oracle, Interbase, Access.

Честно говоря мне не требовалось часто составлять отчеты. Решаемые задачи имели другой онлайновый характер, генерация интерфейса с пользователем по текущему содержимому БД, обработка иерархических зависимостей для Интернет-хостинга (сложный каталог ресурсов с разделенными правами для пользователей типа LDAP). Если хотите управлять генерацией отчета (при большом объеме выводимых данных, красивых постраничных формах и пр), советую и Вам создать универсальную процедуру. Увы, тогда преимущества SQL сойдут на нет.

Для разных задач хороши разные средства. Zigzag может быть полезен, если желаете удивить чем-нибудь, особенно связанным с современными объектными технологиями. Кстати, топик-то об объектных расширениях. Почему Вас все время тянет на то, что является устаревшим и уже не интересным? Ведь есть интересные темы, например в статье Точка Зрения на ОРСУБД
13 апр 06, 19:15    [2560598]     Ответить | Цитировать Сообщить модератору
 Re: ОРБД. сравнение объектных расширений реляционных СУБД.  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
okdoky

Увы, тогда преимущества SQL сойдут на нет.

Размечтались. Пока что конкуренты SQL за всю его историю сходили на нет. А Зигзаг, наверняка, не выдержал бы конкуренции с ними. Впрочем, судя по Вашим постам, Вы не в курсах в чем же преимущества SQL. Типа полагаетесь на свою интуицию. Но она Вас подводит практически во всех Ваших постах. Так Вы SQL не победили бы даже если бы у Вас было что-то реальное, а не то что с каким-то там Зигзагом. Правда, если бы знали, то такими тулсами как Зигзаг, врядли бы пытались с ним бороться.
14 апр 06, 00:07    [2561397]     Ответить | Цитировать Сообщить модератору
 Re: ОРБД. сравнение объектных расширений реляционных СУБД.  [new]
mir
Member

Откуда: Томск
Сообщений: 1027
Хотел было спросить, уж не сам ли Okdoky накропал эту статью по ZZ ("Точка Зрения на ОРСУБД"). Много там знакомых фразочек, которые у него встречались. Однако решил, что все же нет. Хотя степень невежества и непрофессионализма автора статьи Сергея Савушкина столь же велика, как и у Okdoky, он все же поглаже излагает. Похоже, Okdoky просто этой статьи в свое время начитался.
14 апр 06, 06:19    [2561640]     Ответить | Цитировать Сообщить модератору
 Re: ОРБД. сравнение объектных расширений реляционных СУБД.  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
okdoky
Важно, что все SQL-задачи на Zigzag решаются. А вот обратное, как выяснилось, не всегда.
Вспомнил вот. Хоть и не скромно конечно. Вот задача. Есть решение на SQL. Судя по тому как Вы ZZ описываете, вполне вероятно что он для этих целей больше подходит.
Напишите как это на ZZ будет, ведь все SQL-задачи на Zigzag решаются

Про аудит и ведение счетов, я понял, что нам уже не дождаться
14 апр 06, 10:37    [2562344]     Ответить | Цитировать Сообщить модератору
 Re: ОРБД. сравнение объектных расширений реляционных СУБД.  [new]
XaMeL
Guest
-------------
okdoky
vadiminfo
okdoky

Не забывайте, что Zigzag – ОРСУБД.

А вот тут извените. Это как раз можно таки и забыть - Зигзаг как ОРСУБД в литературе не прописан и врядли может реально сопоставляться с реальными ОРСУБД. Ему товарищь все-таки скорее Клиппер, а не Ораклы со Скулями, ДиБиДвами и Сибэйсами. Так шо пусть он пока (до выяснения каких-то новых обстоятельств) остается просто Зигзагом без всяких там приписок типа ОРСУБД.
На счет Оракла и Клиппера не знаю, но взгляните на сайт Most Popular in Database. Sav ZAPI (старая версия Sav Zigzag) тягается с MySQL, PostgreSQL и SQL Server . Согласен, это произошло недавно, но такие темпы меня настораживают самого.


okdoky, сам-то понял, на какую х#$ню ссылка?
Если Zigzag работает с большими XML БД, чем он лучше Berkly? Где можно скачать более новую версию Zigzag 7.4?
30 май 06, 08:56    [2718739]     Ответить | Цитировать Сообщить модератору
 Re: ОРБД. сравнение объектных расширений реляционных СУБД.  [new]
okdoky
Member

Откуда:
Сообщений: 349
XaMeL
Если Zigzag работает с большими XML БД, чем он лучше Berkly? Где можно скачать более новую версию Zigzag 7.4?
Уже существует 8-я версия Sav Zigzag.

Мы делали только самое общее сравнение Sav Zigzag с Berkeley DB XML. Судя по описанию Berkeley, как и Zigzag, действительно очень быстро обрабатывают XML и используют индексацию при работе с иерархическими данными. Самым важным у Berkeley DB XML, конечно является поддержка XQuery! Пока она достаточно сырая ИМХО. Zigzag был реализован раньше, чем XQuery. На основе Zigzag уже внедрены и работают серверные системы, доступные даже из мобильного телефона, если интересно, это: хостинг Smanshome и очень быстрая справочная Организации Москвы (Smanswer).
31 июл 06, 12:04    [2944698]     Ответить | Цитировать Сообщить модератору
 Re: ОРБД. сравнение объектных расширений реляционных СУБД.  [new]
okdoky
Member

Откуда:
Сообщений: 349
Не думаю, что объектные расширения являются главным ориентиром развития СУБД. Более того, убежден, что ОО системы (в том числе ОСУБД), следует считать совершенно новым классом систем (т.е. не СУБД). Да, современные ОО системы базируются на СУБД..., но ведь и СУБД базируются на файловых системах… :)

Фундаментальное направление развития СУБД следует искать в усложнении структуры представляемых ими данных и языковых инструментах, позволяющих обрабатывать эти структуры. Очевидно XML и XQuery – главные направления, на которые сейчас ориентируются IBM, Oracle и Microsoft - http://www.citforum.ru/database/articles/xquery_1.0/.
31 июл 06, 16:23    [2946512]     Ответить | Цитировать Сообщить модератору
 Re: ОРБД. сравнение объектных расширений реляционных СУБД.  [new]
Изопропил
Member

Откуда:
Сообщений: 31627
okdoky
Не думаю, что объектные расширения являются главным ориентиром развития СУБД. Более того, убежден, что ОО системы (в том числе ОСУБД), следует считать совершенно новым классом систем (т.е. не СУБД). Да, современные ОО системы базируются на СУБД..., но ведь и СУБД базируются на файловых системах… :)


Можно поподробнее с этого места - насчёт базирования на файловых системах?
То, что такие СУБД имеются, не означает, что "СУБД базируются на файловых системах"
31 июл 06, 16:43    [2946683]     Ответить | Цитировать Сообщить модератору
 Re: ОРБД. сравнение объектных расширений реляционных СУБД.  [new]
AlexTheRaven
Member

Откуда: Москва
Сообщений: 879
okdoky
<...>и очень быстрая справочная Организации Москвы (Smanswer).

Тому может быть 1000 причин, но субъективно форум sql.ru работает в разы быстрее. Особенно когда щёлкаю на "Аптека" и после получаю на экране "346 objects". Время ожидания - до 3 секунд, на таких смешных объёмах - многовато.
31 июл 06, 17:55    [2947147]     Ответить | Цитировать Сообщить модератору
 Re: ОРБД. сравнение объектных расширений реляционных СУБД.  [new]
okdoky
Member

Откуда:
Сообщений: 349
AlexTheRaven
okdoky
<...>и очень быстрая справочная Организации Москвы (Smanswer).

Тому может быть 1000 причин, но субъективно форум sql.ru работает в разы быстрее. Особенно когда щёлкаю на "Аптека" и после получаю на экране "346 objects". Время ожидания - до 3 секунд, на таких смешных объёмах - многовато.
Ответ в 3 сек оценивать бессмысленно. Вы забыли, что это Интернет? Объем БД не влияет существенно на производительность. Вы забыли принципы индексации? Время отклика в основном зависит от объема искомых данных, особенно если система пытается их (или их количество) выдать сразу.

Решил проверить сам, как быстро работает поиск в SQL и в справочной. Сделал такие запросы:
Аптека | Цена | разработка - для SQL
Аптека, Цена, разработка - для Smanswer.
Получил результаты:
найдено 213 тем за 9 сек - для SQL
найдено 578 объектов за 6 сек - для Smanswer.
31 июл 06, 18:37    [2947352]     Ответить | Цитировать Сообщить модератору
 Re: ОРБД. сравнение объектных расширений реляционных СУБД.  [new]
okdoky
Member

Откуда:
Сообщений: 349
Изопропил
Можно поподробнее с этого места - насчёт базирования на файловых системах?
То, что такие СУБД имеются, не означает, что "СУБД базируются на файловых системах"
Зачем Вам файловые системы? Вы обратили внимание на мордочку :)?

Три категории, о которых шла речь, и их зависимость можно, например, представить так:
файловые системы (с прямым и последовательным доступом) -> СУБД -> ОО системы (например Hibernate, JDO)
31 июл 06, 18:55    [2947419]     Ответить | Цитировать Сообщить модератору
 Re: ОРБД. сравнение объектных расширений реляционных СУБД.  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
okdoky
Не думаю, что объектные расширения являются главным ориентиром развития СУБД. Более того, убежден, что ОО системы (в том числе ОСУБД), следует считать совершенно новым классом систем (т.е. не СУБД). Да, современные ОО системы базируются на СУБД..., но ведь и СУБД базируются на файловых системах… :)

Фундаментальное направление развития СУБД следует искать в усложнении структуры представляемых ими данных и языковых инструментах, позволяющих обрабатывать эти структуры. Очевидно XML и XQuery – главные направления, на которые сейчас ориентируются IBM, Oracle и Microsoft - http://www.citforum.ru/database/articles/xquery_1.0/.


Объектные расширения и есть "усложнения" структуры в данном контексте. Точнее претендуют на ПО более сложной структуры. И естественно претендуют на обработку этой структуры. Т.е. они как бы укладываются в эти "фундаментальные направления".

Если же они не СУБД, как сказано у автора, но базируются на СУБД, то они просто проги к БД. Не СУБЗ же они в самом деле? (Если, конечно, не обращать внимания на Селебрум Шуклина).

Что до очевидности того, что "XML и XQuery – главные направления, на которые сейчас ориентируются IBM, Oracle и Microsoft", то это не совсем пока очевидно. Напрмер, Оракл приписал новым версиям букву "g", а не "х". Т.е. не XML они считают главным, а гриды, в 8 и 9 версиях было "i" - интернет - ближе к XML. Это скорей лишь одна из составляющих какого-то такого фундаментального направления.
31 июл 06, 20:35    [2947695]     Ответить | Цитировать Сообщить модератору
 Re: ОРБД. сравнение объектных расширений реляционных СУБД.  [new]
ABC_1982
Member

Откуда: Москва
Сообщений: 418
okdoky
...
Решил проверить сам, как быстро работает поиск в SQL и в справочной. Сделал такие запросы:
Аптека | Цена | разработка - для SQL
Аптека, Цена, разработка - для Smanswer.
Получил результаты:
найдено 213 тем за 9 сек - для SQL
найдено 578 объектов за 6 сек - для Smanswer.

Н-да... Сравнил, называется...
1 авг 06, 07:50    [2948351]     Ответить | Цитировать Сообщить модератору
 Re: ОРБД. сравнение объектных расширений реляционных СУБД.  [new]
AlexTheRaven
Member

Откуда: Москва
Сообщений: 879
okdoky
<...>Ответ в 3 сек оценивать бессмысленно. Вы забыли, что это Интернет? Объем БД не влияет существенно на производительность. Вы забыли принципы индексации? Время отклика в основном зависит от объема искомых данных, особенно если система пытается их (или их количество) выдать сразу.

Про объём у меня вообще ни слова не было. Про неопределённость Интернет - нет, не забыл. Потому и написал про 1000 причин. И не собираюсь путать мягкое с тёплым - есть технология и есть реализация. Но IMHO не стоит называть очень быстрым то, что очень полезно, но работает медленно. Ну пусть на запрос-ответ уходит 1 сек. Всё равно, 2 секунды считать 400 записей - многовато даже для перегруженной производственной БД.

okdoky

Получил результаты:
найдено 213 тем за 9 сек - для SQL

Как удалось? :) Разрешите поинтересоваться, не MySQL ли Denwer'а использовалась с установками по умолчанию?
1 авг 06, 10:30    [2948893]     Ответить | Цитировать Сообщить модератору
 Re: ОРБД. сравнение объектных расширений реляционных СУБД.  [new]
Nikolay Kulikov
Member

Откуда: Москва
Сообщений: 607
okdoky ты недопонимаешь XQuery имеeт место в индустрии. Отнюдь не потому что это супер прорывные идея, хотя в их реализации в внутри любой БД есть много интересных вещей.

Появление возможностей XML внутри БД связано с потребностью хранить его в БД (на данный момент факт, то что XML является результатом множества транзакций во всем мире) В США до и после Enron и им подобных появилось огромадное количество требований по хранению данных финансовых транзакций. Если результатом является XML, то нужно хранить XML. Но не просто хранить но и эффективно по нему искать.

Так что в первую очередь деньги, а потом уже технологии. Я думаю что у немногих компаний которые сейчас занимаются XML БД есть шансы превратится в что то подобное DB2/MSSQL/Oracle в мире реляционных БД. А те у которых такие шансы есть, скорее всего будут скуплены вышеупомянутой тройкой

А так по большому счету XML внутри БД очень сильно похож на объектные расшинения БД. Вводится новый базовый тип под названием XML
И самом деле завязан на объектные расшинения (по крайней мере для DB2)

Да кстати если ты отслеживашь последние тенденции в этой области, то XQuery уже не актуально. Актуален XUpdate.
1 авг 06, 10:56    [2949121]     Ответить | Цитировать Сообщить модератору
 Re: ОРБД. сравнение объектных расширений реляционных СУБД.  [new]
okdoky
Member

Откуда:
Сообщений: 349
AlexTheRaven
Тому может быть 1000 причин, но субъективно форум sql.ru работает в разы быстрее. Особенно когда щёлкаю на "Аптека"…

okdoky
Решил проверить сам, как быстро работает поиск в SQL и в справочной. Сделал такие запросы:
Аптека | Цена | разработка...

AlexTheRaven
okdoky

Получил результаты:
найдено 213 тем за 9 сек - для SQL

Как удалось? :) Разрешите поинтересоваться, не MySQL ли Denwer'а использовалась с установками по умолчанию?
Я отвечал на ваш первый пост. Конечно речь идет об sql.ru. А вот какая система поддерживает сайт sql, это вопрос не ко мне? Не думаю, что MySQL Denwer'а…
1 авг 06, 14:02    [2950521]     Ответить | Цитировать Сообщить модератору
 Re: ОРБД. сравнение объектных расширений реляционных СУБД.  [new]
okdoky
Member

Откуда:
Сообщений: 349
Конечно, когда я говорю об XML, XQuery, Zigzag и пр. как об основных ориентирах или главных направлениях развития СУБД, не подразумеваю, что именно они будут основным языковым интерфейсом будущих СУБД. Возможно, это будет какой-нибудь SQLX или что-то в этом роде. Например, XML худо-бедно еще можно использовать для внутренних межмашинных протоколов и представления реляционно-иерахических структур, но не как основной способ ввода данных человеком. Взгляните, как будет выглядеть одна и та же структура
на XML
<A>
  <C a=’1’/>
</A>
<B>
  <C a=’1’/>
</B>
на Zigzag
[A,B]:C(a:1)=
На SQL это уж пусть vadiminfo изголяется, ему не привыкать придумывать идентификаторы …

ОСУБД - прошлый этап. Зачем vadiminfo их вытаскивает? Они никак не могут быть сегодняшним ориентиром развития СУБД. Из ОО-систем работающих с объектами и хранящих их в БД, наиболее популярны сейчас серверы приложений. Но это не значит, что их нужно называть СУБД и на «проги» они не тянут…
1 авг 06, 18:51    [2952621]     Ответить | Цитировать Сообщить модератору
 Re: ОРБД. сравнение объектных расширений реляционных СУБД.  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
okdoky

ОСУБД - прошлый этап. Зачем vadiminfo их вытаскивает?

Не мне их вытащить, но и не okdoky задвинуть их. Тем более таким способом и на таком уровне рассуждений.

Насчет того, где искать фундаментальные направления - ну что-то же надо искать. Ни ООСУБД, ни XML и тем более Зигзага лично я к фундаментальным направлениям не привистовывал. Первые два просто какие-то направленния (не фундаментальные скорее всего), третье , если и направление то назад, в лучшем случае в сторону от развития.

okdoky

Фундаментальное направление развития СУБД следует искать в усложнении структуры представляемых ими данных и языковых инструментах


Т.е. надо объяснить када их от туда (из усложненных структур) успели убрать.

Тогда как XML не на усложнение структуры, а на полуструктурированные МД претендовал. Т.е. не заменяет ОО в смысле структур - у стуктурированных и полуструктурированных свои достоинства и недостатки, не позволяющие во всех случаях предпочесть что-либо одно. Возможно, для okdoky такие мелочи не имеют значения. Однако, перед начертанием направления поиска фундаментальных направлений по признаку усложнения структур, этим бы стоило хоть немного озаботиться.

Конечно, никто не подозревает okdoky в том, что он просто опять вытащил Зигзага, и подстраивает под него якобы фундаментальные направления развития БД (чего мелочиться то?). Тогда бы, действительно, усложнения структур это просто то, что первое пришло в голову ему, после того как никаких достоинств среди СУБД сегодняшнего дня (т.е. накануне фундаментального развития) у Зигзага выявить ему ранее не удалось.

okdoky

Они никак не могут быть сегодняшним ориентиром развития СУБД.


Ну, okdoky конечно видней в общем случае ориентиры развития СУБД. Однако, если он там увидел совершенно случайно Зигзага, то он погорячился, скорее всего.

okdoky

Из ОО-систем работающих с объектами и хранящих их в БД, наиболее популярны сейчас серверы приложений.


Ноу каментс.

okdoky

Но это не значит, что их нужно называть СУБД и на «проги» они не тянут…

Это , скорей всего, ничего не может значить.
Нужно ли называть Весант СУБД или нет, конечно, дело версантников, но пока в литератре его за СУБД считают. И только ради вытаскивания Зигзага любой ценой, они вряд ли от этого откажутся.
1 авг 06, 22:00    [2952952]     Ответить | Цитировать Сообщить модератору
 Re: ОРБД. сравнение объектных расширений реляционных СУБД.  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
okdoky
Взгляните, как будет выглядеть одна и та же структура
на XML
<A>
  <C a=’1’/>
</A>
<B>
  <C a=’1’/>
</B>
на Zigzag
[A,B]:C(a:1)=
На SQL это уж пусть vadiminfo изголяется, ему не привыкать придумывать идентификаторы …

При большой вложенности на XML будет наглядней(когда не понять какая скобка что закрывает)
И еще: XML не предназначен для хранения и манипулирования данными, его удобно использовать как формат передачи данных. Поэтому и функции в разные SQL-и вводятся как раз для того чтоб взять эти данные и дальше уже работать с ними "по-человечески".
Ну и говорить "а как это структура будет выглядеть на SQL?" - по меньшей мере неграмотно.
2 авг 06, 10:22    [2953881]     Ответить | Цитировать Сообщить модератору
 Re: ОРБД. сравнение объектных расширений реляционных СУБД.  [new]
okdoky
Member

Откуда:
Сообщений: 349
SergSuper:
Для наглядности можно делать отступы. На счет манипулирования, XSLT по своей сути - XML, то есть XML позволяет манипулировать данными. Что значит XML не предназначен для хранения? Можно хранить в форме XML. Хотя согласен, это больше способ представления данных (как и таблицы).

vadiminfo:
Если вы до сих пор не работаете с сервером приложений, например Oracle Application Server 10g , комментировать действительно нечего. Я уже полтора года работаю с WebLogic, до этого с JBoss. Если вам так нравится называть их ОРСУБД, называйте. ОК, будем считать что вы не согласны с моей градацией
файловые системы (с прямым и последовательным доступом) -> СУБД -> ОО системы (например Hibernate, ...)
Эта градация действительно условна...
2 авг 06, 17:37    [2957036]     Ответить | Цитировать Сообщить модератору
 Re: ОРБД. сравнение объектных расширений реляционных СУБД.  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
okdoky
Для наглядности можно делать отступы.
Можно. Но если скобку пропустил - разобраться где всё равно тяжело будет. Ну а вообще между тем что Вы написали на зигзаге и XML-е я принципиальной разницы не вижу.
На счет манипулирования, XSLT по своей сути - XML, то есть XML позволяет манипулировать данными.
Не покажите ли как мне с помощью XSL-T проапдейтить XML?
Да и вообще по поводу XSL-T у меня цензурных слов нет
Что значит XML не предназначен для хранения? Можно хранить в форме XML.
Можно и в Ворде хранить
Хотя согласен, это больше способ представления данных (как и таблицы).
Это именно промежуточный (в частности транспортный) формат
2 авг 06, 18:15    [2957225]     Ответить | Цитировать Сообщить модератору
 Re: ОРБД. сравнение объектных расширений реляционных СУБД.  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
okdoky

vadiminfo:
Если вы до сих пор не работаете с сервером приложений, например Oracle Application Server 10g , комментировать действительно нечего.
...

Нет комментариев от того, что, например, использование Application Server 10g не делает систему с Ораклом ОО - системой. Равно как этого не далают клиентские приложения использующие парадигму ООП. В общем случае сервер приложений вовсе не отменяет использование СУБД, в том числе и ООСУБД. Была двухзвенка, с сервером приложений - стала трехзвенка. Отмена из-за этого сервера БД не предполагается. А Вы вывели, что ООСУБД не СУБД раз там есть сервер приложений или ООСУБД стали не нужны, если вообще Ваша фраза (как впрочем и другие якобы задвигающие ООСУБД) может быть как-то переведена.

okdoky

Я уже полтора года работаю с WebLogic, до этого с JBoss. Если вам так нравится называть их ОРСУБД, называйте. ОК, будем считать что вы не согласны с моей градацией
...

На них мне забить. А наравится мне ОРСУБД называть СУБД Оракл. А Версанта нравится называть ООСУБД не зависмо от того с чем Вы работали или использовали, но в силу того, что они таковыми признаются в более авторитетных источниках. Если Вы не использовали сервер БД или использовали Зигзаг (что возможно одно и то же), то этого недостаточно чтобы ООСУБД оказалось задвинутым.
Про Вашу градацию - не смешите меня.

okdoky

файловые системы (с прямым и последовательным доступом) -> СУБД -> ОО системы (например Hibernate, ...)
Эта градация действительно условна...

Может лучше было Вам больше технолгиями БД заниматься, а не с серверами приложений работать, чтобы лучше представлять себе приложения БД? Тада бы Вы не выдумывали условных градаций, а пользовались бы классификацией систем БД, предложенной более продвинутыми спецами и описанными в толстых книгах. И уж точно не связались бы с Зигзагом.
2 авг 06, 22:50    [2957793]     Ответить | Цитировать Сообщить модератору
 Re: ОРБД. сравнение объектных расширений реляционных СУБД.  [new]
okdoky
Member

Откуда:
Сообщений: 349
SergSuper
>Не покажите ли как мне с помощью XSL-T проапдейтить XML?
XSLT обычно используется как фильтр, позволяющий из одного XML-файла делать другой, соответственно апдейтить исходный файл. У XQuery намечаются еще интереснее возможности, ориентированные специально на XML БД - Расширение языка XQuery функциональными update-выражениями.

vadiminfo
Что вы все доказываете и выдвигаете? Я давно с вами согласился. Конечно, если стулом забивать гвозди, то его вполне можно назвать молотком. Давайте договоримся на том, что О(Р)СУБД это СУБД на которой могут базироваться ОО-системы, а ОО-системы использующие БД – не О(Р)СУБД. И вам хорошо и мне тоже. ОК?
3 авг 06, 14:20    [2960405]     Ответить | Цитировать Сообщить модератору
 Re: ОРБД. сравнение объектных расширений реляционных СУБД.  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
okdoky
SergSuper
>Не покажите ли как мне с помощью XSL-T проапдейтить XML?
XSLT обычно используется как фильтр, позволяющий из одного XML-файла делать другой, соответственно апдейтить исходный файл. У XQuery намечаются еще интереснее возможности, ориентированные специально на XML БД - Расширение языка XQuery функциональными update-выражениями.

Ну дык Вы попробуйте напишите такой XSL, который допустим в Вашем XML-е заменит "1" на "2". Модификации как таковой нету, есть создание на основе данных старого.
Про то что в XQuery намечается - ну не серьёзно, двоим чего-то в голову пришло, но какое отношение они имеют к стандартизации языка? Мало ли кому еще чего придёт.
3 авг 06, 16:56    [2961636]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 [4] 5   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить