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 может быть полезен, если желаете удивить чем-нибудь, особенно связанным с современными объектными технологиями. Кстати, топик-то об объектных расширениях. Почему Вас все время тянет на то, что является устаревшим и уже не интересным? Ведь есть интересные темы, например в статье Точка Зрения на ОРСУБД

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).

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

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

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

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

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

Три категории, о которых шла речь, и их зависимость можно, например, представить так:

AlexTheRavenТому может быть 1000 причин, но субъективно форум sql.ru работает в разы быстрее. Особенно когда щёлкаю на "Аптека"…
okdokyРешил проверить сам, как быстро работает поиск в SQL и в справочной. Сделал такие запросы:
Аптека | Цена | разработка...
AlexTheRaven okdoky
Получил результаты:
найдено 213 тем за 9 сек - для SQL
Как удалось? :) Разрешите поинтересоваться, не MySQL ли Denwer'а использовалась с установками по умолчанию?Я отвечал на ваш первый пост. Конечно речь идет об sql.ru. А вот какая система поддерживает сайт sql, это вопрос не ко мне? Не думаю, что MySQL Denwer'а…

Конечно, когда я говорю об XML, XQuery, Zigzag и пр. как об основных ориентирах или главных направлениях развития СУБД, не подразумеваю, что именно они будут основным языковым интерфейсом будущих СУБД. Возможно, это будет какой-нибудь SQLX или что-то в этом роде. Например, XML худо-бедно еще можно использовать для внутренних межмашинных протоколов и представления реляционно-иерахических структур, но не как основной способ ввода данных человеком. Взгляните, как будет выглядеть одна и та же структура
на XML
на Zigzag
На SQL это уж пусть vadiminfo изголяется, ему не привыкать придумывать идентификаторы …

ОСУБД - прошлый этап. Зачем vadiminfo их вытаскивает? Они никак не могут быть сегодняшним ориентиром развития СУБД. Из ОО-систем работающих с объектами и хранящих их в БД, наиболее популярны сейчас серверы приложений. Но это не значит, что их нужно называть СУБД и на «проги» они не тянут…

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

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

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

vadiminfo
Что вы все доказываете и выдвигаете? Я давно с вами согласился. Конечно, если стулом забивать гвозди, то его вполне можно назвать молотком. Давайте договоримся на том, что О(Р)СУБД это СУБД на которой могут базироваться ОО-системы, а ОО-системы использующие БД – не О(Р)СУБД. И вам хорошо и мне тоже. ОК?