В DB2 встроенный XML более гибок, чем у Oracle. В Oracle особенно когда надо работать с посторяющимеся структурами типа
<employee id>
....
<phone>123</phone>
<phone>432</phone>
</employee>

phone сложно будет развалится в CLOB

Зачем нужен XML в БД. За тем что XML уже не только формат обмена информацией, но и является артефактом транакций (покупка акций - документ, поставка - документ)

На западе все помешались на Regulatory Compliance и документы нужно хранить в оригинальном формате без изменений и быстро предоставлять статистику по интересующей информации в гос органы.

Так же если строить mapping из XML в Relational Tables в некоторых случаях потребуется для полного соотвествия иметь порядка 300 таблиц, так как стандарты преиодически меняеются и дополняются, можно оценить количество гемороя при изменении mappings.

Так же интересная тема это привязка пунктов контракта - который хорошо описывается в XML к определенным данным и изменениям этих даных в оперативных системах. Надеюсь достаточно примеров зачем XML класть в БД

А преимущества использования БД в Web было интересно и актуально лет 6 назад, сейчас у всех вендоров есть эквивалентные инструменты. Вплоть до конфигурации Web Services из запросов и хранимых процедур на уровне конфиграционных файлов.

2SergSuper
автор
всего 300? А чего не 1000 или миллион?
Две таблицы или три я еще могу понять как использовать, но вот больше - уже не укладывается в голове


300 из реального проекта. Если ты не видел таких потребностей, это не означает что их нет
всегда найдется кучка требования которые превратят простую схему из 2-3 таблиц в 200-300.

2softwarer
автор
Если я правильно понял, Вы говорите о хранении xml в базе на уровне примечаний, поля типа memo. Согласен, может потребоваться.

Я сделал четкую оговорку, требования госрегуляторов. Как ты представляешь себе поиск в миллионах документах в поле memo? О производительности не думал?

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

softwarer
Во-первых, ты сказал не о поиске в миллионах документах, а о статистике по этим документам. Не
знаю как для тебя, для меня это вовсе не синонимы.


ok что ты подразумеваешь под стастистикой которую надо передавать регуляторам?

softwarer
Во-вторых, я говорил о роли этой информации в жизни приложения, а не о реализации ее "полем типа memo", тем паче что такой тип вроде бы канул в прошлое вместе с xBase.

Наконец, если хочешь поговорить именно о поиске в clob-полях - естественным решением являются соответствующие индексы. Если мне не изменяет память, в поддержке полнотекстовых индексов для Oracle была соответствующая фича, начиная с 10gR2 существует XMLINDEX, наконец если сильно хочется, можно написать собственный.


Про это я написал, проиндексируй XMLINDEX в Oracle тэги которые может дублироваться
<employee>
<phone>
<phone>

Про собственный индекс не смеши, сколько компаний которые пользуются этой фичей в Oracle?

softwarer
Стоит ли продолжать ожидать ответов на прочие заданные вопросы?


Спрашивающих много я один, если честно не в ближайшие две недели.

SergSuper
У нас есть такие приборы!!!
Но мы вам о них не расскажем(С)
Каждый из нас видел множество глупостей(да и делал, чего душой кривить-то), не исключаю что это одна из них. Во всяком случае Вы никаких аргументов или причин что бы плодить столько таблиц не привели

Причина как минимум одна, если у тебя много документов, сколько строк у тебя будет в 2-3 таблицах? Отсюда полезут уши производительности etc...
Я не спорю о том, что можно красиво и аккуратно разложить XML данные в 2-3 таблицы и до определенного объема это будет работать великолепно. Я говорю о том, что есть некоторая граница после которой эту схему придется расширять и причем существенно. Главный послыл, то что все зависит от конкретных условий, а когда все зависит от конкретных условий и частностей, желательно иметь в БД возможности которые упростять работу и не приведут к существенному увеличению кол-ва таблиц. Про случай с 300 таблиц в детали вдаваться не могу NDA, но постараюсь к середине декабря закинуть некоторый нейтральный пример который покажет преимущества хранения XML в БД.

Если кому-то не ответил, могу попробовать ответить через mail