Gluk (Kazan)Запихни туды справочник метров на 100 и наблюдай как XML будет делять из него выборку одной записи

Возьмите к примеру простой контракт, ну эдак страниц на 20-30.
Чтобы текст там был, Параграфы, пункты, подпункты, таблицы - графики платежей, реквизиты сторон, особые условия. И помните, что один контракт от другого может весьма существенно отличаться. Единственное что у них совпадает - так это структура. И попытайтесь:

1) разложить все это по таблицам
2) собрать все это из таблиц чтобы снова напечатать.

Сколько таблиц у вас получится?
Сколько запросов понадобится нарисовать чтобы вывести все это на печать?

Я полагаю что это одна сторона вопроса - стоит или нет.
Вторая сторона - это то, что XML в настоящее время де-факто представляет собой своеобразный эсперанто для компьютерных систем. Без такого языка вавилонскую башню всяко не построить.

А вообще всякую систему нужно делать соответствующими средствами.

> Атрибуты документов - 2-3 таблицы.
Ну-ну...

>надо получить объект Документ, запросов при этом будет несколько выполнено
А одним запросом слабо?... И чтоб быстро :) Без тормозов...

>Без знания о том, что какой элемент дерева документа означает,...
в том то и вся прелесть что довольно легко одни XML документ конвертируется в другой XML, который уже понимается нужной системой :)
На то и существует XQuery.

Ну я все равно подожду DB2 v9 (Viper) где это будет все в native виде :)

Ок!)
Пока что я продолжу изыскания в области XMLSchema,XQuery.
Посмотрим что у меня получится. Месяца через 3-4 вернемся к этой теме.

Цита из вышеприведенной ссылки:
//
Я добиваюсь от многих команд разработчиков, чтобы они не хранили XML в базе данных как столбец varchar большой длины или text. Это превра­щает ее в не более чем простое хранилище XML. Конечно, это нарушает один из принципов устройства базы данных — атомарность, или, в очень свободной трактовке, — один столбец, одно значение. Как может СУБД поддерживать какую­либо целостность в столбце, содержащем XML? (А разве это невозможно? просто понятие целостности в трактовке XML несколько другое чем в РБД) Как я узнаю, что разные строки XML, хранящиеся в данной таблице, имеют какие­то отношения? Индексирование и оптимизация по такой схеме невозможны. ( кстати- возможно... ) (На заметку: когда эта статья была впервые опубликована, Microsoft как раз упомянула, что Yukon будет иметь тип данных XML. Сейчас SQL Server 2005 практически готов, и в нем планируется встроенная в базу данных поддержка XML. Независимо от того, насколько хорошо Microsoft сможет реализовать сжатие и индексирование на типе данных XML, он все равно подходит только для иерархических данных и не годится для общего управления данными.)
//

Никто не сомневается, что плоские таблицы хранить в XML - бред.
Но, XML как альтернатива BLOB/CLOB всеже имеет право жить в СУРБД.
Например перемещать узлы,удалять, добавлять не меняя документа вцелом - разве это не благо? Насколько я знаю сейчас BLOB/CLOB приходится менять полностью при UPDATE.

Помните, когда-то базы данных были вообще без LOB. Их дабавили - никто не умер, как и никто не кинулся их юзать. Просто добавление поддержки XML к РБД это просто еще одна возможность. Еще один инструмент. И, типа, интсрументом пользоваться надо уметь.

Прикиньте такую ситуацию.
Было три приложения. Обменивались они инфой. Вдруг понадобилось расширить количество данных передаваемых из приложения 1 в 2.
Фомат обмена нужно менять. А как быть с 3 приложением? Если используем
XML - то 3 приложение может вытащить только то, что ему нужно. Теккстовый формат тут не катит. Конечно же есть накладные расходы. Но факт тот, что есть и возможность. Сейчас подобные вещи реализуются через DBF. Ну а если идет обмен по сети? Это уже о web вебсервисах.
Я абсолютно согласен что это гораздо медленнее чем бинарные данные.
Но в некоторых случаях это приемлемо, этого хватает и это работает.

Еще мысль: может XML заменит DBF?
Ведь чем DBF хорош - он в себе несет достаточно много метаданных. Но XML в этом плане на порядок круче. Уже сейчас многие конторы сдают обязательную отчетность в XML а не в dbf. Пройдет еще лет 10-20, уйдет поколение Clipper/FoxPro-2.X и останется XML или какая-нибудь производная от него.

Впрочем ждем Viper.

На счет избыточности XML.
На самом деле XML в дереве хранится не в виде текста (или не совсем в виде текста). Имена атрибутов и элементов находятся в параллельном иерархическом справочнике. Поэтому из-за этого справочника имеется даже некая доля компресии.

А вообще XML хорошо подходит для сериализации объектов которые трудно представить в виде одной плоской таблицы. Сериализация естественно предполагает обмен :)

ЗЫ. Я к BerkeleyXML DB не имею никакого отношения.
Но надеюсь автор топика расскажет о результатах своих исследований. :)

mir gardenmanв виде одной плоской таблицыА бывают плоские и неплоские таблицы?

Естественно. Бывают многомерные таблицы (см. MDC в DB2)
и бывает не одна а несколько плоских таблиц, между которыми имеются связи. (например Договор именно так и представляется)

> Более того, это вообще шаг назад к иерархическим БД, проблемы которых давно и хорошо известны. Поэтому использовать этот формат для хранения и обработки данных по-моему нерационально.

Не шаг назад. А диалектическая спираль развития. Возврат к старому, но на новом уровне.
Вспомните: все новое - это хорошо забытое старое

2 mir
Вы в буквальном смысле на меня "наехали".
Чтож, из фразы: одной плоской таблицы . Выбросим слово "плоской". Договорились?