Вот, буквально вчера было опубликовано:
http://www-1.ibm.com/press/PressServletForm.wss?MenuChoice=pressreleases&TemplateName=ShowPressReleaseTemplate&SelectString=t1.docunid=7977&TableName=DataheadApplicationClass&SESSIONKEY=any&WindowTitle=Press+Release&STATUS=publish

Интересно, а то же самое в том же юконе как сделано?
Я вообще слаб в XML, (признаюсь честно) но чувствую, что-то особенное грядет.

http://www.theregister.co.uk/2004/12/09/ibm_database_goalposts/

Как я понял сейчас почти все СУБД хранят XML в BLOB/CLOB. Поэтому, если нужно отредактировать какой-то документ (удалить или вставить узел), то приходится полностью менять этот BLOB/CLOB. А в том, что предлагает IBM - это делать не надо будет. Можно будет просто добавить/удалить/именить узел в самом дереве XML-документа. Типа native XML storage.

Выдержка:

So much for the hard facts; now for some opinion. First, I think this leaves Oracle and Sybase (as the two vendors with the best current handle on XML) well behind the curve, with Microsoft and the others more or less out of sight. What this release will allow you to do is to build applications that handle both XML and relational data much more easily, without losing any of the richness that this implies, and without degrading performance.

Цитата:

Shredding XML to relational tables is expensive at insert
time due to costly XML parsing [10] and multi-table
inserts. But once XML is broken into relational scalar
values, queries and updates in plain SQL promise higher
performance. Still this approach suffers from drawbacks:
XML schemas can have many nested and repeating elements
such that the corresponding relational schema
would consist of dozens or even hundreds of tables. Defining
such a mapping from XML to a relational schema
is a complicated task. Once data has been inserted, any
changes to the relational schema -due to changes in the
XML Schema- are almost always infeasible. This severely
restricts the flexibility which XML is often used for in the
first place. Also, the required multi-way joins to reconstruct
XML documents can be expensive when dealing
with large amounts of data [12]. Beyond that, complex
XQueries can even be untranslatable into SQL [5].

In Oracle 10g XML documents can be stored with indexing
support as CLOBs, shredded to object-relational
tables, or a combination of both [11]. The XML support
in Microsoft SQL Server 2005 stores XML documents as
byte sequences in BLOB columns [12]. A primary XML
index can be defined to avoid parsing the XML BLOBs at
query time [12]. Additionally, secondary XML indexes
can be defined to further increase query performance.
This is somewhat different from DB2’s XML storage and
indexing approach described in sections 4 and 5. In DB2,
XML parsing is never required at query time and indexes
can be defined on specific paths.

Sergey ChВсе равно не понимаю, зачем хранить данные в XML, в то время как есть прекрасно разработанный структуры для хранения и быстрого нахождения данных... А может был прав предствитель MS когда отвечал на мой аналогичный вопрос: "Просто это сегодня модно... эта мода пройдет и все вернется..."
Прикол заключается в том, что на самом деле 80% данных не структурированы.
И, в основнном разработчики "натягивают" их на реляционную модель.

Помнится здесь на этом сайте многие предлагали объектные модели на тему
"как хранить заказ". Типа заказ это - одна или несколько позиций. Позиция это системниый блок, Монитор, клава. Системный блок это ... Ну, короче дерево.Причем все деревья разные, непохожие. Я надеюсь что подход который дает IBM позволит хранить такой "Заказ" как XML документ при этом не снижая производительности.

Аналогично можно поступить с таким понятием как "Договор". Короче - применений масса.

2 Yo!
>> непонял, у ibm сейчас есть аналог оракловых ООП фич

Поподробнее, какие такие ООП фичи вы имеете в виду?

2 Yo!
То, что вы написали.. )) CREATE TYPE , METHOD , METHOD OVERRIDING, TYPED VIEW, TYPED TABLE и прочая лабуда имеется в DB2 c 5-й версии. А сейчас уже 9 к выпуску готовится.