Когда я должен использовать тип данных XML в SQL Server?

Когда я должен использовать тип данных XML в Microsoft SQL Server?

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

Лично я никогда раньше не использовал тип поля XML в SQL Server, и я много занимался программированием баз данных, так как они добавили эту функцию. Мне всегда казалось, что программные и производительные издержки связаны с использованием XML-контента в базе данных изначально. Честно говоря, я думал, что это уловка, потому что в начале 2000-х все были в поезде XML. «О, XML горячий, поэтому давайте добавим его в SQL Server, чтобы мы не выглядели устаревшими».

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

Вероятно, есть десятки других причин, по которым вы хотели бы использовать его, но, честно говоря, я думаю, что вам следует подумать о других путях к счастью, прежде чем стремиться к использованию XML в SQL Server, если у вас нет для этого особых бизнес-причин. Используйте varchar (max) или текстовое поле, если это имеет больше смысла.

Просто мое мнение, конечно :)

Я встречал только несколько сценариев, в которых я бы активно использовал использование типа данных XML в SQL Server. Это от макушки моей головы, от наименее до самого интересного:

• Хранение / архивирование XML-ответов, сгенерированных другими приложениями
  • Например, мы используем Application Integration Framework (AIF) для связи между пользовательским приложением Silverlight и Dynamics AX. Мы храним как входящие, так и исходящие сообщения в базе данных, чтобы помочь в устранении неполадок связи между этими приложениями
  • Поскольку тип поля - XML, а не универсальный тип строки (например, VARCHAR), мы можем использовать XQuery для специального запроса сообщений, соответствующих некоторым конкретным критериям. Это было бы намного сложнее с простым сопоставлением строк
• Кэширование / сохранение составленного ответного сообщения
  • Обновите поле XML с помощью триггера или кода приложения, который будет имитировать вычисляемый столбец
  • Вместо того, чтобы постоянно генерировать ответ XML для вызывающего приложения на основе, вы бы понесли издержки только тогда, когда строка вставлена, а не при каждом вызове.
  • Это работает лучше всего, когда SELECTs встречаются гораздо чаще, чем UPDATE / INSERT, что имеет место для большинства приложений.
• Хранение нескольких значений в одном поле
  • Одна из практик, которые я видел, - это использование типа данных XML для хранения коллекции значений в одном поле.
  • Одним из преимуществ является то, что вам не нужно создавать дополнительный набор таблиц для простого хранилища ключей / значений.
  • Недостатком этого является то, что данные не полностью нормализованы, что делает запросы менее очевидными
  • Однако, как упоминалось выше, вы можете использовать XQuery в этом поле XML для выбора строк, которые соответствуют критериям идентификации, тем самым частично нейтрализуя влияние неполной нормализации.

Тем не менее, в 99% случаев мне совершенно не нужно поле XML при разработке схемы.

Несколько раз я видел тип данных XML на SQL-сервере, он в основном использовался как поле, которое запрашивалось, как и любое другое в базе данных, что может иметь очень плохие последствия для производительности, если у вас большой объем данных , Есть причина, по которой он называется SQL-сервером, а не XML-сервером. :-) Запросы, которые идут против XML, просто не так быстры, как выполнение обычного запроса выбора.

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

Я использовал поля типа XML в основном для целей ведения журналов, связанных с веб-сервисами ASMX или сервисами WCF. Вы можете сохранить запрос или ответные сообщения.

В большинстве случаев вы сохраняете XML в БД для справочных целей, а не для обычной деловой активности (чтобы не запрашивать его каждые 5 секунд из кода). Если вы обнаружите, что делаете это, определите поля, которые вы обычно запрашиваете или используете большую часть времени, и создайте для них отдельные столбцы. Таким образом, когда вы сохраняете XML в БД, вы можете извлечь эти поля и сохранить их в соответствующих столбцах. Позже при их получении вам не нужно будет запрашивать документ XML, вы можете просто использовать столбцы, созданные для этой цели.

Вот сценарии, которые приходят в голову прихотливо, когда они рассматривают, какие условия должны были бы существовать, чтобы разрешить поля XML в Sql Server:

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

Я широко использую XML в клиент-серверных приложениях для сохранения структурированных данных в одном обращении к базе данных. В качестве примера возьмем счет-фактуру с подробными строками. Легко заставить клиента сериализовать бизнес-объект в XML и передать хранимому процессу за один вызов. Процесс решает, требуется ли вставка или обновление; он может получить идентификатор родительского счета-фактуры (столбец идентификаторов) для назначения подробным записям, все в рамках транзакции на стороне сервера, и клиенту не нужно совершать несколько циклов. Мне не нужно 20 или около того параметров, чтобы указать запись заголовка, и мне не нужно делать вызов для каждой строки счета. Кроме того, часто можно вносить изменения в схему или вводить протоколирование / аудит, не касаясь клиента.