Когда я могу сохранить данные JSON или XML в таблице SQL

основные вопросы

• что вы собираетесь делать с этими данными? и
• как вы фильтруете / сортируете / соединяете / манипулируете этими данными?

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

XML / JSON и 1.NF

первое правило нормализации предписывает никогда не хранить более одного бита информации в одном столбце. Вы видите столбец "PersonName" со значением типа "Микки Маус"? Ты указываешь на это и кричишь:--23-->изменить это немедленно!

как насчет XML или JSON? Эти типы ломают 1.НФ? Ну, и да, и нет... 

совершенно нормально хранить полное структура как один бит информации если это один бит информации на самом деле. Вы получаете ответ SOAP и хотите сохранить его, потому что вам может понадобиться это для дальнейшего использования (но вы будете не использовать эти данные для собственных процессов)? Просто храните его как!

теперь представьте себе сложная структура (XML или JSON), представляющая человека (С его адресом, дальнейшие подробности...). Теперь вы положите это в одна колонка как PersonInCharge. Это неправильно? Разве это не должно жить в правильно разработанных связанных таблицах со ссылкой на внешний ключ вместо XML / JSON? Особенно, если один и тот же человек может встречаться во многих разных строках, определенно неправильно использовать подход XML/JSON.

но теперь представьте себе необходимость хранения исторических данных. Вы хотите остаются данные человека на данный момент времени. Через несколько дней человек сообщает вам новый адрес? Нет проблема! Старый адрес живет в XML / JSON, если он вам когда-либо понадобится...

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

физическая хранения

следующий для SQL Server и может отличаться от других СУРБД.

XML хранится не как текст, который вы видите, а как дерево иерархии. Это удивительно хорошо работает! Эта структура не анализируется на уровне строки!
JSON в SQL Server (2016+) живет в строке и должен быть проанализирован. Нет реального родной типа JSON (как есть родной типа XML). Это может произойти позже, но сейчас я бы предположил, что JSON не будет таким же эффективным, как XML на SQL Server (см. раздел обновление 2). Нужно прочитать значение из JSON потребуется чертовски много скрытых вызовов метода string...

что это значит для вас?

код привлекательный DB художник :-D не знает, что хранение JSON как, противоречит общим принципам РСУБД. Он знает,

• что JSON, скорее всего, нарушает 1.NF
• что JSON может измениться во времени (тот же столбец, разное содержимое).
• что JSON не является легко читать, и очень трудно фильтровать/искать/присоединяться или Сортировать по нему.
• что такие операции перенесут довольно дополнительную нагрузку на бедный маленький сервер БД

есть некоторые обходные пути (в зависимости от используемых СУБД), но большинство из них не работают так, как вам хотелось бы...

ответ на ваш вопрос короче

да

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

нет

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

вы можете начать с JSON в строковом столбце или как BLOB и изменить это на физические таблицы, когда вам это нужно. Мой магический хрустальный шар говорит мне, что это может быть завтра : - D

обновление

найдите некоторые идеи о производительности и дисковом пространстве здесь:https://stackoverflow.com/a/47408528/5089204

обновление 2: подробнее о производительности...

следующий адреса поддержки JSON и XML в SQL-Server 2016

пользователь @mike123 указал на статья в официальном блоге microsoft что, кажется, доказывает в эксперименте, что запрос JSON является 10 x быстрее затем запрос XML в SQL-Server.

некоторые мысли об этом:

некоторые перекрестные проверки с "эксперимент":

• на "эксперимент" измеряет много, но не работу с XML и JSON с. Выполнение одного и того же действия agaist одной и той же (неизмененной) строки повторно не является реалистичным сценарием
• проверенные примеры далеко до простого для общего заявления!
• значение read всегда одно и то же и даже не используется. Оптимизатор увидит это...
• ни единого слова о могучем XQuery поддержка! Найти продукт с заданным ID в массив? JSON должен прочитать всю партию и используйте фильтр после использования WHERE, а XML позволит внутренняя XQuery predicate. Не говоря уже о FLWOR...
• "эксперименты" код как в моей системе появляется: JSON кажется 3x быстрее (но не 10x).
• добавлять /text() до XPath уменьшает это до менее чем 2x. В соответствующей статье пользователь "Mister Magoo" указал на это уже, но click-bait название еще не менявшийся...
• С таким легким JSON, как указано в "эксперименте", самый быстрый чистый подход T-SQL был комбинацией SUBSTRING и CHARINDEX : - D

следующий код покажет более реалистичный эксперимент

• использование JSON и идентичного XML с более чем одним Product (массив JSON против родственных узлов)
• JSON и XML немного меняются (10000 запущенных номеров) и вставляются в таблицы.
• существует начальный вызов agaist обе таблицы, чтобы избежать первый звонок-уклон
• все 10000 записей считываются и полученные значения вставляются в другую таблицу.
• используя GO 10 будет проходить через этот блок десять раз, чтобы избежать первый звонок-уклон

конечный результат ясно показывает, что JSON медленнее, чем XML (не так много, около 1.5 x на все еще очень простой образец.)

в заключительном заявлении:

• С чрезмерно упрощенным примером при неоправданных обстоятельствах JSON может быть быстрее, чем XML
• работа с JSON чистое действие строки, в то время как XML анализируется и преобразуется. Это довольно дорого в первом действии, но ускорит все, как только это будет сделано.
• JSON может быть лучше в один раз действие (избегает накладных расходов на создание внутреннего иерархическое представление XML)
• С еще очень простым, но более реалистичным примером XML будет быстрее в простом чтении
• всякий раз, когда есть необходимость прочитать определенный элемент из массива, отфильтровать все записи, где данный ProductID включен в массив, или перемещаться вверх и вниз по пути, JSON не может задерживаться. Он должен быть полностью разобран из строки - каждый раз, когда вам нужно схватиться за нее...

тест код

USE master;
GO
--create a clean database
CREATE DATABASE TestJsonXml;
GO
USE TestJsonXml;
GO
--create tables
CREATE TABLE TestTbl1(ID INT IDENTITY,SomeXml XML);
CREATE TABLE TestTbl2(ID INT IDENTITY,SomeJson NVARCHAR(MAX));
CREATE TABLE Target1(SomeString NVARCHAR(MAX));
CREATE TABLE Target2(SomeString NVARCHAR(MAX));
CREATE TABLE Times(Test VARCHAR(10),Diff INT)
GO
--insert 10000 XMLs into TestTbl1
WITH Tally AS(SELECT TOP 10000 ROW_NUMBER() OVER(ORDER BY (SELECT NULL))*2 AS Nmbr FROM master..spt_values AS v1 CROSS APPLY master..spt_values AS v2)
INSERT INTO TestTbl1(SomeXml)
SELECT 
N'<Root>
    <Products>
    <ProductDescription>
        <Features>
            <Maintenance>' + CAST(Nmbr AS NVARCHAR(10)) + ' year parts and labor extended maintenance is available</Maintenance>
            <Warranty>1 year parts and labor</Warranty>
        </Features>
        <ProductID>' + CAST(Nmbr AS NVARCHAR(10)) + '</ProductID>
        <ProductName>Road Bike</ProductName>
    </ProductDescription>
    <ProductDescription>
        <Features>
            <Maintenance>' + CAST(Nmbr + 1 AS NVARCHAR(10)) + ' blah</Maintenance>
            <Warranty>1 year parts and labor</Warranty>
        </Features>
        <ProductID>' + CAST(Nmbr + 1 AS NVARCHAR(10)) + '</ProductID>
        <ProductName>Cross Bike</ProductName>
    </ProductDescription>
    </Products>
</Root>'
FROM Tally;

--insert 10000 JSONs into TestTbl2
WITH Tally AS(SELECT TOP 10000 ROW_NUMBER() OVER(ORDER BY (SELECT NULL)) AS Nmbr FROM master..spt_values AS v1 CROSS APPLY master..spt_values AS v2)
INSERT INTO TestTbl2(SomeJson)
SELECT 
N'{
    "Root": {
        "Products": {
            "ProductDescription": [
                {
                    "Features": {
                        "Maintenance": "' + CAST(Nmbr AS NVARCHAR(10)) + ' year parts and labor extended maintenance is available",
                        "Warranty": "1 year parts and labor"
                    },
                    "ProductID": "' + CAST(Nmbr AS NVARCHAR(10)) + '",
                    "ProductName": "Road Bike"
                },
                {
                    "Features": {
                        "Maintenance": "' + CAST(Nmbr + 1 AS NVARCHAR(10)) + ' blah",
                        "Warranty": "1 year parts and labor"
                    },
                    "ProductID": "' + CAST(Nmbr + 1 AS NVARCHAR(10)) + '",
                    "ProductName": "Cross Bike"
                }
            ]
        }
    }
}'
FROM Tally;
GO

--Do some initial action to avoid first-call-bias
INSERT INTO Target1(SomeString)
SELECT SomeXml.value('(/Root/Products/ProductDescription/Features/Maintenance/text())[1]', 'nvarchar(4000)')
FROM TestTbl1;
INSERT INTO Target2(SomeString)
SELECT JSON_VALUE(SomeJson, N'$.Root.Products.ProductDescription[0].Features.Maintenance')
FROM TestTbl2;
GO

--Start the test
DECLARE @StartDt DATETIME2(7), @EndXml DATETIME2(7), @EndJson DATETIME2(7);

--Read all ProductNames of the second product and insert them to Target1
SET @StartDt = SYSDATETIME();
INSERT INTO Target1(SomeString)
SELECT SomeXml.value('(/Root/Products/ProductDescription/ProductName/text())[2]', 'nvarchar(4000)')
FROM TestTbl1
ORDER BY NEWID();
--remember the time spent
INSERT INTO Times(Test,Diff)
SELECT 'xml',DATEDIFF(millisecond,@StartDt,SYSDATETIME());

--Same with JSON into Target2
SET @StartDt = SYSDATETIME();
INSERT INTO Target2(SomeString)
SELECT JSON_VALUE(SomeJson, N'$.Root.Products.ProductDescription[1].ProductName')
FROM TestTbl2
ORDER BY NEWID();
--remember the time spent
INSERT INTO Times(Test,Diff)
SELECT 'json',DATEDIFF(millisecond,@StartDt,SYSDATETIME());

GO 10 --do the block above 10 times

--Show the result
SELECT Test,SUM(Diff) AS SumTime, COUNT(Diff) AS CountTime
FROM Times
GROUP BY Test;
GO
--clean up
USE master;
GO
DROP DATABASE TestJsonXml;
GO

результат (SQL Server 2016 Express на Acer Aspire v17 Nitro Intel i7, 8GB Ram)

Test    SumTime 
------------------
json    2706    
xml     1604