Хранение «словарей» и «массивов» в SQL Server

Question

Я ищу несколько советов о том, как хранить данные типа «массивы» и «словари» в базе данных SQL Server 2012. До сих пор я использовал тип XML, как я могу запросить это легко, и они могут быть просто представлены, например:

<Array><i>1</i><i>2</i><i>3</i></Array> 
<Dictionary><Item1>Value1</Item1><Item2>Value2</Item2></Dictionary> 

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

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

[ID] bigint PK, 
[OwnerID] bigint, 
[Name] varchar(32), 
[Value] varchar(32) 

И массив:

[OwnerID] bigint PK 
[Index] int PK 
[Value] varchar(32) 

Это будет работать, но я беспокоюсь о том, как «Queryable» этот метод будет - то есть «WHERE ObjectId в X словарь правильно = Y '. Я мог бы написать скалярную функцию для этого, но я знаю, что это вызовет проблемы с производительностью.

Я прочитал эту конкретную проблему, но общий консенсус, похоже, «использует столбец xml и не беспокоится об этом», но учитывая объем данных, который мне нужно разрешить, Думаю, это вариант для меня.

Любые советы или идеи были бы очень оценены.

Answer 1

Столбец XML является блоб, что позволяет делать запросы на него ...

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

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

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

Наконец, с точки зрения использования диска, и поскольку вы планируете такие объемы, хранилище не должно быть проблемой, это должно быть требование (IMO).