alexeyvgМы обсуждали, нужно-ли при хранении XML указать констрейн по XSD для этого XML
Ответ - нет, не нужно, и делать так неправильно.Тема - типичный "сферический конь".
Реализация XML полностью зависит от вида СУБД. В DB2 и, если не ошибаюсь, в Оракле поле XML может хранить документы с разными схемами, тогда все схемы регистрируются в БД и каждая запись может соответствовать своей схеме. Тогда оно и нужно, и правильно.
В MS SQL, насколько помню, допустима только одна схема на поле, да и хранение не бинарное. У остальных РСУБД XML в еще более противозачаточном состоянии (если вообще есть), и тут уже надо извращаться с декомпозицией. Или взять правильную СУБД :)

Alexander_111Милай, для чего XML созавался? Ответ: совместно описывать и хранить данные и метаданные.Милай, как раз создавался он просто как стандартизированное человекопонятное средство обмена для B2B. И метаданные в нем не хранятся, а хранятся они именно в XSD, по которому документы валидируются. Потом уже к нему прикрутили XSLT для трасформаций, XPath для навигации и XQuery для запросов/модификаций.
Alexander_111Весь вопрос в том, как и что системы с этим делать могут. Вот DB2 и Oracle по XSD создают объекты и сохраняют структуру и данные XML в БД. Другие это делать не умеют. Объясняешь любопытным умам, что данные в XML type таблицах и содержимое XML файлов - одно и тоже, так ведь не доходит. В репозтарии файл будет лежать, но с пустым размером, но если его извлечь, то он будет наполнен содержимым. Контент это называется...Мне не понятна Ваша приверженность к декомпозиции XML в реляционные структуры. Это хорошо только в весьма частных случаях. В остальном "хорошие" в смысле XML СУБД позволяют работать с ним как со сколь угодно строго типизированными иерархиями, эффективно обрабатывая именно навигацию по "лесу" деревьев, для чего реляционные структуры предназначены плохо. И еще хуже они предназначены для XML с меняющимися метаданными, т.е. XSD.
Не зря все-таки XQuery ввели в стандарт SQL, начиная с SQL:2003.

alexeyvgИмеем от разных контрагентов поток запросов в виде xml-пакетов
Каждый xml-пакет сохраняем и присваиваем ему входящий номер
Клиенту посылаем тикет по обработке этого пакета с результатом (может быть и многофазная обработка - принял, распарсил-проверил, обработал, но эти детали к вопросу не относятся)
Детали хранения XML нужно описывать исходя из его структуры и использования. Если это "глубокое" дерево, если обрабатывать его надо именно как дерево, а не как список, если XSD часто меняется или вообще отсутствует - нужна СУБД с нормальными XML-полями.
Если все проще или деревья не используются - можно и в реляционную структуру заносить.
Если же XML нужен только как протокол передачи вполне себе реляционных данных - и говорить не о чем, можно тупо скормить XSLT и получить плоский файл для импорта, например.

alexeyvgВопрос - что делать, если полученный xml не верифицируется ни по одной из схем?
Если он вообще невалидный как xml (например, количество скобок не соответствует) - не хранить? забить? Типа - у нас всё правильно и не колышет?

На мой взгляд, если хранить входящие данные в БД, то правильнее хранить входящий пакет "как есть", хранить те байты, которые поступили.Хранить приходящие "со стороны" пакеты нужно практически всегда "как есть", но только для архива после парсинга (зипом их и в BLOB, например).
Если XML не верифицируется по указанной в нем схеме, тем более вообще как XML - это ошибочный документ, и обрабатывать его просто опасно в смысле целостности данных. Если данные в нем хоть кому-то нужны, его надо просмотреть человеком и вылечить или запросить повторно.

Alexander_111Вот уж перепутал, Милай, что курица, а что яйцо... Первична структура и данные, а форма вторична. XML - форма, РДМ - тоже форма. Так чем одна форма лучше другой?Милай, тяжело мне не запутаться, ибо "форма данных" - понятие для меня новое и неизученное. Можно ссылку? :)
Я знаю понятие "модель данных". Модели суть: реляционная, иерархическая, сетевая, объектная... XML есть частный случай слаботипизированной иерархии. Его можно сделать сильнотипизированной иерархией с помощью XSL, являющимся метаданными отн. валидируемых по нему XML. Модели отн. друг друга не лучше и не хуже - они разные, а вот эмуляция одной одели с помощью другой, например декомпозиция XML в реляционные таблицы, связана с серьезными накладными расходами.
Alexander_111Почему это ОРМ плохо обрабатывает деревья? Вы такое Oracle не брякните, засмеют...Я где-то написал, что плохо? Оракл прикрутил для обработки XML имеющееся у него иерархическое расширение, а в DB2 сделали отдельный XML движок. Умеет Оракл хранить в одой таблице XML с разными схемами? А вообще без схемы, но именно как дерево с эффективной навигацией и индексированием? Если нет - плохо, если да - причем тут ОРМ, разве он не просто реализация хранения? Просветите, а то я XML в Оракл знаю слабо.
Alexander_111XQUERY скрестили с SQL и что? Раньше все запросы к серверам любого типа шли через буферы запросов. XQUERY ничем не отличается, как задается путь к узлу по тегам (XPATH), так и я в буферах запросов задавал такие-же пути. В другой форме, но смысл от этого не меняется, Милай.Ктож их скрещивал-то? XQuery - отдельный язык. Какая связь между ним, "узлами" и "буферами запросов"? Или "буфера запросов" - это что-то Оракл-срецифичное? Дайте ссылку, а то под это словосочетание подходит куча разных технологий.
Alexander_111В чем вопрос, меняется структура - как ее отследить? Выход - все просто хранить в файловом виде в файловом репозитарии. Что пришло, то пусть и лежит. И обрабатывать средствами XML парсера. Но нужны XSD, чтобы отпарсить.Опять - "где футбол, а где Житомир"(С)? Что хранить в файлах - XSL? И зачем тогда СУБД? Подход в DB2: меняется структура - в БД регистрируется новый XSL - новые XML валидируются по ней, старые лежат как лежали со ссылкой на старый XSL. В Оракл так нельзя? Если нет - я думал о нем слишком хорошо.
Alexander_111Если XSD нет, то XML - простой текст. И его надо обрабатывать как текстовую информацию. Что тут-то не понятно?Не понятно, с каких пор XML стал "простым текстом". Он - по определению иерархия. Просто без XSL - иерархия строк, без бинарных типов. Иерархический способ его хранения и доступность для индексирования и XQuery в DB2 при этом никак не меняется.

alexeyvg...Тут у меня другой взгляд на обработку...
Речь тут идёт не о xml-файле, присылаемом письмом раз в неделю, а о, например, сообщениях от смс-агрегаторов, которые идут потоком, и обработать ошибку вручную по каким-нибуть текстовым логам программы-парсера невозможно.Сойдемся на том, что обработка ошибок - дело крайне зависящее от задачи и общих рецептов тут не бывает.
В любом случае, если пришедший XML невалидный, автоматически его обрабатывать надо с большой осторожностью, т.к. ошибочный документ с большой вероятностью просто испорчен и может содержать ошибочные данные.