Каково ограничение производительности для типа данных XML в SQL Server по сравнению с NVARCHAR (MAX)?

У меня есть база данных, которая будет хранить записи журнала.

Один из столбцов в таблице журналов содержит сериализованные (для XML) объекты, а парень из моей группы предлагает использовать XML-тип данных, а не NVARCHAR (MAX). В этой таблице будут храниться журналы "навсегда" (архивирование некоторых очень старых записей может быть рассмотрено в будущем).

Я немного беспокоюсь о накладных расходах процессора, но меня больше беспокоит, что БД может расти быстрее (FoxyBOA из упомянутого вопроса получил 70% большую БД при использовании XML).

Я прочитал этот question, и он дал мне несколько идей, но мне особенно интересно выяснить, увеличивается или уменьшается размер базы данных.

Можете ли вы поделиться своим пониманием/опытом в этом вопросе.

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

Ответы

Ответ 1

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

Если вы вставляете 5000 строк XML 5KB в столбец XML, вы получаете примерно 1250 страниц = 9 МБ. Вставка тех же 5000 строк с одним и тем же 5KB XML в NVARCHAR (MAX) использует более 3700 страниц или 29 МБ - довольно большая разница!

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

И я не согласен с тем, что использование XML над NVARCHAR (MAX) имеет любое ограничение производительности - совсем наоборот. Поскольку вы потенциально извлекаете меньше данных из SQL Server, когда собираетесь отображать или извлекать контент, я бы сказал, что он даже чуть быстрее, чем NVARCHAR (MAX).