Зачем мне вообще хранить и манипулировать XML в реляционной базе данных?

Вы можете хранить там XML, сгенерированный пользователем.

Если веб-сайт, такой как stackoverflow, использовал какую-то разметку XML вместо разметки, вы могли бы сохранить вопрос / ответы как XML в базе данных. Вы можете обнаружить, что пытаетесь проанализировать этот созданный пользователем XML в поисках проприетарных тегов.

Допустим, у вас есть объект с атрибутами. Вы можете хранить все эти атрибуты в XML вместо создания отдельной таблицы атрибутов. XML был бы более гибким.

Если вы не видите в этом необходимости, не меняйте!

Иногда вам нужно сохранить данные, структура которых неизвестна, или ее структура очень изменчива. В этих случаях вместо создания таблицы просто сохраните XML в существующей таблице.

Гибкость - одна из причин.

Если структура ваших данных может меняться, вы все равно можете сохранить общую таблицу РСУБД вместе с запросами и т. д., Которые после нее будут содержать несколько изменчиво структурированные данные.

Если вам нужно добавить поле в какой-то момент, вы можете сделать это, не изменяя структуру таблицы RDMS и, таким образом, не нарушая запросы всех остальных.

Вы можете обрабатывать XML-данные непосредственно на SQL-сервере. Например. вы можете применять выражения XPath и просто отправлять отфильтрованный набор результатов клиенту. Возможности SQL-сервера могут основываться на возможностях обработки XML позже.

Вышеуказанные функции существуют из MS SQL Server 2000 или 2005.

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

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

Кроме того, я полагаю, что некоторые DMBS с хорошей поддержкой XML могут позволить вам просто сохранить XML-документ, возможно, без указания того, как его индексировать. Вы просто используете XQuery и надеетесь, что он каким-то образом оптимизируется в соответствии с вашими потребностями.

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

Вот реальный пример системы, над которой я работаю. У нас есть базовая система, и мы создаем индивидуальный для клиента код на java. В зависимости от того, какой клиент совершает транзакцию, может вызываться другой класс. Иногда этому пользовательскому коду нужно что-то хранить, и мы помещаем это в столбец XML в соответствующей таблице. Это избавляет нас от моделирования всего, что находится под солнцем. Добавление нового клиента обычно означает просто написание и установку кода Java.

Обратной стороной является то, что отчеты, запросы и обновления в столбце XML сложнее. Нет ни одной из обычных хороших функций базы данных, таких как проверочные ограничения и т. д.

У меня пока не было необходимости хранить XML, но я часто использую возможность возвращать XML из хранимой процедуры. Это делает некоторые вещи очень полезными - в основном отчеты. Я могу запустить SP, чтобы сгенерировать отчет, отправить обратно результаты в XML, а затем использовать XSLT, чтобы очень легко отобразить результат на сайте.

Я использую тип столбца XML для хранения копий всех критически важных для бизнеса сообщений, которые мы получаем от сторонней службы. Это очень удобно по нескольким причинам.

1) В случае повреждения данных мы можем выполнить обратную трассировку, чтобы узнать, какие данные поступили, когда и в каком формате. 2) Дальнейшие работы по развитию систем могут быть основаны на реальных данных из таблицы журнала - просто десериализуйте и используйте данные, как если бы они были получены в результате вызова службы 3p
3) Убедитесь, что специалисты по инфраструктуре заняты выделением дискового пространства серверу БД. ;)

Единственная причина, по которой я когда-либо буду использовать его снова, - это расширяемость и гибкость.

Накладные расходы на xml (xpath) и обслуживание (пространства имен) действительно не стоят хлопот, если вы можете их избежать. Ранее мы хранили большие объемы данных в xml и использовали скалярные функции для их извлечения, но это слишком медленно и вызывает огромные головные боли из-за изменений структуры xml или пространства имен.

Но гибкость просто фантастическая. Вы можете добавлять новые свойства, когда захотите, у вас могут быть данные, специфичные для проекта / клиента / задания, для которых не требуются соответствующие столбцы. XML не обязательно должен иметь статическую структуру - вам просто нужна фабрика, которая может порождать экземпляры для работы с различными XML (которые должны быть связаны с проектом / клиентом / заданием).

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

Таким образом, вы не начинаете с помещения основных свойств в XML. Но вам следует добавлять XML, когда вы знаете, что ваша таблица может нуждаться в расширении, именно потому, что это дает вам возможность расширения.