SQL Server增加JSON支持

DECLARE @JSalestOrderDetails nVarCar(2000) = N '{"OrdersArray": [

{"Number":1, "Date": "8/10/2012", "Customer": "Adventure works", "Quantity": 1200},

{"Number":4, "Date": "5/11/2012", "Customer": "Adventure works", "Quantity": 100},

{"Number":6, "Date": "1/3/2012", "Customer": "Adventure works", "Quantity": 250},

{"Number":8, "Date": "12/7/2012", "Customer": "Adventure works", "Quantity": 2200}

]}';

SELECT Number, Customer, Date, Quantity

FROM OPENJSON (@JSalestOrderDetails, '$.OrdersArray')

WITH (

Number varchar(200),

Date datetime,

Customer varchar(200),

Quantity int

) AS OrdersArray

• 迁移——我们发现，人们早已将JSON存储为文本，因此，如果我们引入一种单独的JSON类型，那么为了使用我们的新特性，他们将需要修改数据库模式，并重新加载数据。而采用现在这种实现方式，开发者不需要对数据库做任何修改就可以使用JSON功能。
• 跨功能的兼容性——所有SQL Server组件均支持NVARCHAR，因此，JSON也将在所有的组件中得到支持。开发者可以将JSON存储在Hekaton、时态表或列存储表中，运用包括行级安全在内的标准安全策略，使用标准B树索引和FTS索引，使用JSON作为参数或返回过程值，等等。开发者不需要考虑功能X是否支持JSON ——如果功能X支持NVARCHAR，那么它也支持JSON。此外，该特性有一些约束——Hekaton及列存储不支持LOB值，所以开发者只能存储小 JSON文档。不过，一旦我们在Hekaton及列存储中增加了LOB支持，那么开发者就可以在任何地方存储大JSON文档了。
• 客户端支持——目前，我们没有为客户端应用程序提供标准JSON对象类型（类似XmlDom对象的东西）。自然地，Web和移动应用程序以及JavaScript客户端将使用JSON文本，并使用本地解析器解析它。在JavaScript中，可以使用object类型表示JSON。我们不太可能实现一些仅在少数RDBMS中存在的JSON类型代理。在C#.Net中，许多开发者使用内置了JObject或JArray类型的 JSON.Net解析器；不过，那不是一种标准，也不太可能成为ADO.NET的一部分。即便如此，我们认为，C#应用可以接受来自数据库层的纯字符串，并使用最喜欢的解析器解析它。我们所谈论的内容不只是跟应用程序有关。如果开发者试图在SSIS/SSRS、Tableau和Informatica ETL中使用JSON列，它们会将其视为文本。我们认为，即使我们增加了JSON类型，在SQL Server之外，它仍将被表示成字符串，并根据需要使用某个自定义的解析器解析它。因此，我们并没有找到任何重大的理由将其实现为一种原生JSON类型。