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

Question

Современные СУБД имеют поддержку типов столбцов XML и функциональность для работы с XML в хранимых процедурах. Исторически я всегда отображал иерархические данные (объекты OO или XML) в реляционные таблицы. Учитывая широкую поддержку XML для базы данных, я должен изменить свои пути?

Answer 1

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

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

Answer 2

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

Answer 3

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

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

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

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

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

Answer 4

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

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

Answer 5

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

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

Answer 6

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

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

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

Answer 7

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

Answer 8

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

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

Answer 9

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

Answer 10

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

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

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