Определение, сохранить ли данные XML как XML или в нормализованных таблицах
(Это сообщение требует личного опыта о хранении XML; совместно используйте то, что Вы знаете.:-))
Я работаю над сервисным приложением, которое общается с внешним сервисом с помощью XML. Я планирую использовать SQL Server 2008 для хранения XML, который получен и отправлен внешней службе. Я исследую свои опции для хранения XML в базе данных. Три опции, которые я определил:
- Сохраните XML в, данные XML вводят столбец
- Составьте таблицы для хранения различных родительских и дочерних отношений, представленных в XML.
- Гибрид двух выше подходов, где исходный XML хранится в данные XML, вводит столбец, но несколько полей от XML, вспыхнувшего в их собственные столбцы для упрощения запросов и индексации.
Я ищу любой совет, на основе Вашего личного опыта, с хранением и получением данных XML в SQL Server.
Некоторый дополнительный фон: я использовал 'xsd.exe' эквивалентный названный XsdObjectgenerator для создания классов .NET на основе XML-схем. Когда сервис получает XML-файл, он десериализовывается в экземпляр класса .NET. Этот экземпляр используется для выполнения операций сервиса. Мой первоначальный план состоял в том, чтобы затем использовать опцию № 1 выше для хранения XML. Если бы я должен был обновить или сообщить относительно данных, то я просто десериализовал бы запись дб назад в один из моих классов .NET.
Хотя этот подход работает и делает работу с xml очень простым, у меня есть опасения, что как объем увеличений данных, выполнение запросов записей типа данных XML уменьшится. Поэтому я исследовал опции 2. И 3. выше.
В дополнение к хранению XML XML будет запрошен для использования в обоих отчетах и отдельном веб-приложении. Записи дб будут запрошены, отсортированы, фильтрованы, сгруппированы, summaried и возможно обновлены конечными пользователями.
3 ответа
Думаю, это зависит от того, что вы хотите делать с вашим XML в своей базе данных.
Если вы в основном просто храните его и, возможно, извлекаете его позже целиком и отправляете снова, то я бы определенно использовал тип данных XML - нет смысла дробить его на части.
Если вам, однако, необходимо в основном работать с содержимым XML-файла, а также, возможно, манипулировать и изменять это содержимое, тогда может быть целесообразно создать таблицы со столбцами, соответствующие вашему XML-содержимому, и измельчить его при сохранении, используйте его, а когда вам нужно, соберите его из реляционных частей, используя что-то вроде SELECT (columns) FROM dbo.Table FOR XML .....
На измельчение и повторную сборку связаны накладные расходы, поэтому вам нужно спросить себя, стоит ли это делать. Но есть также накладные расходы, если вам нужно слишком много манипулировать столбцом XML.
Если вам нужен доступ только для чтения к нескольким атрибутам в вашем XML, я оценил возможность обернуть их в UDF и отобразить его как вычисляемый столбец в вашей таблице. Таким образом, вы можете легко выбрать что-нибудь из своей таблицы на основе значений, которые хранятся где-то внутри вашего XML - это очень удобно! Но не злоупотребляйте этим подходом - он отлично работает для 2, 3 атрибутов - но если вам нужно снова и снова обращаться к вашему XML (и большей части или ко всему), тогда вам может быть лучше для начала разбить его на реляционные части. .
Продолжая изучать решения, коллега отправил следующие применимые ссылки:
- Производительность SQL Server с ключом / парой Таблица против поля XML и XPath
- Поддержка XML в Microsoft SQL Server 2005
Некоторые предварительные выводы из этих статей и других исследований:
- При работе с типом данных xml в SQL Server гибкий, запрос больших объемов данных будет быть медленным, поскольку вы по сути запрашиваете тип данных blob.
- Хотя вы можете создавать индексы для столбцов типа данных xml в Sql Server, индекс применяется ко всему столбцу, а не к конкретному элементу или атрибуту, поэтому индексы не так эффективны, как индекс для столбца, отличного от xml db.
- Сохранение xml в необработанном виде в xml поле типа данных при сохранении проанализированная версия данных в либо реляционные таблицы, либо денормализованный плоский стол (ы) для запросы и отчеты начинаются стать наиболее гибким решение. XML можно "измельчить" в таблицы запросов либо в время выполнения или постфактум отдельный сервис или поток.
Я буду моделировать каждое решение с тестовыми данными и выполнять некоторые тесты. Я опубликую здесь результаты, когда они будут доступны.
Несколько лет назад (SQL 2000) мы хранили XML как текстовые данные, и наши базы данных значительно раздулись - не столько из-за данных, сколько из-за тегов, используемых для их идентификации. Я провел некоторые испытания, и pkzip (я сказал, что это было несколько лет назад) уменьшил все данные до 3% от их первоначального размера.
Совет #1: Определите, как долго вам нужно хранить данные, и по возможности архивируйте старые данные.
Совет #2: Если вы используете SQL 2008, изучите возможности сжатия данных для столбцов XML.
(Может быть, это не имеет значения, если ваши XML короткие, но наши были все в кбс и 10 кбс.)
.