Было время, когда я работал в страховании. И есть иакм такое понятие - объект страхования. Т.е. понимается под этим все что угодно. Вот, давайте попробуем эту самую сущность и все ее подтипы разложить по реляционным таблицам. Так вот, этих самых таблиц получется - океан и писать SQL для этого окенана - тихий ужас. А работать он будет - не факт что очень быстро.
Да и количество соединений в операторе ограничено. А с другоны - мне отдельная таблица на всякий подтип - нахрен не нужна. Я б вообще описание объекта хранил в CLOB. однако, иной раз исходя из свойств объекта я должен рассчитать тариф - а из CLOB слишком тяжко выковыривать данные. из XML - всяко попроще. А если потом нужно всю эту гадость напечатать, красиво отформатировать? - приходится лазить по всем таблицам и собирать всю эту кашу в один горшок. ИМХО - подобный стиль построения систем не очень производителен. За кучей таблиц в модели иной раз не видно сути проекта.

1024Глупости какие. В структурированном виде хранящиеся данные обрабатывать проще чем неструктурированном или полуструктурированном. На языке SQL. И скорость будет выше (обратных примеров не встречал).

ХМЛ нужен чтоб "как у всех". Ну и если есть какие-то оригиналы которые на XPath запросы пишут а SQL выучить не смогли то им проще будет.

Глупости какие. Неструктурированные данные проще обрабатывать на XQuery. не всякий объект можно описать строкой в таблице. Не всякий набор объектов легко ложится на реляционную модель. Можно воспринимать XML как способ увеличить функциональность BLOB/CLOB.