原文地址：http://www.ncloud.hk/%E6%8A%80%E6%9C%AF%E5%88%86%E4%BA%AB/built-in-json-support-in-sql-server-2016/
在数据库层对JSON提供支持，是请求排名最靠前的特性之一，在Microsoft Connect网站上对他的投票量超过了1000。微软承诺，在Sql Server 2016版本中，会提供内置的JSON支持。注意这并不是Sql Server 2005已有特性XML原生支持的翻版。微软的目标是创建一个简单好用的框架来处理JSON文档。本文中，我将描述SQL Server 2016中计划实现的JSON特性。特性支持时间表如下：
- SQL Server 2016 CTP2 － 能够把数据格式化为JSON导出，关于该特性的详细信息情参阅博文。
- SQL Server 2016 CTP3 － 能够加载JSON字符串并解析为表变量，能够提取JSON节点的值，对JSON列设置索引属性。
JSON 数据的存储形式
首先我们要搞明白的是，内置JSON支持并不等于原生JSON类型。在SQL Server 2016中，JSON数据将会使用NVARCHAR类型存储，原因如下：
- 可迁移性 － 我们发现人们已经开始使用字符串来表示JSON数据，如果引入新的JSON类型，人们不得不改变数据库架构，并且使用新的特性来重新载入数据。
- 特性兼容性 － NVARCHAR数据类型已经被SQL Server的各个组件广泛支持，这样JSON也就被这些组件支持。你可以把JSON放进Hekaton，Temporal或者column store表中，应用行级别的权限控制等安全策略，使用B-Tree和FTS索引，把JSON作为存储过程或用户自定义函数的参数与返回值等。你无需考虑JSON是否与某个特性X兼容，因为只要NVARCHAR与特性X兼容，那么JSON也就兼容。此外也有一些限制，由于Hekaton和column store不支持LOB值，因此你职能保存小型JSON文档，但是，一旦我们为Hekaton和column store添加了对LOB的支持那么你就能够把JSON文档存储在任意地方了。
- 客户端代码兼容性 － 当前在客户端应用中我们还没有标准的JSON对象类型（向XmlDom对象）。网页、移动端和JavaScript应用使用内置的解析器把JSON文本转化为对象。在JavaScript中使用object来表示JSON数据，不可能为少数关系型数据库内建JSON 类型提供一个代理类型。在C#.Net中，大量开发者使用JSON.net解析器和内建的JObject、JArray类型；但是这些不是标准方案，且可能不会被纳入ADO.NET，所以C#应用从数据库得到纯文本JSON后使用自己喜欢的解析器进行处理。
注意你仍然可以使用自己的能通过CLR实现的JSON类型，引入JSON.NET或其他相似的库。即使你不喜欢编码实现CLR用户自定义类型，也可以下载大量现成的实现，这样你不需要注意原生JSON类型和用户自定义JSON类型之间的差异。只要对于大多数.Net应用来说足够快就可以了。如果你觉得PostgreSQL的JSONB格式或则zipped JSON text等压缩格式更好，那么你可以通过UDT来使用他们， 可以创建成员方法来利用那种格式的属性。当前我们还没有发现有谁在尝试使用UDT来封装JSONB格式，因此，在Sql Server 2016中不考虑JSONB格式。
我们的焦点在于提供更好的函数和更优的查询性能，而不在于节约存储空间。我们知道在PostgreSQL中有原生JSON类型和对JSONB的支持，但是我们不确定其性能与CLR方式相比是否更有优势，所以，在SQL Server 2016中，我们决定关注于其他更重要的方面（你希望看到在SQL Server中有原生的JSON类却没有相关的内建函数吗？我想答案是否定的）。但是，我们会在社区中与大家讨论，是否大家认为使用原生的JSON类型比CRL JSON或则文本JSON更好，你可以在Microsoft Connect网站上创建话题与我们讨论。我们决定首先实现FOR JSON和OPENJSON还由于该特性是大量用户都需要的，并且通过CLR难以实现。
因此，我们的关注重点是导出／导入遗迹一些内建的JSON处理函数。有人可能会说这些函数的性能还不够快。我们的策略是先提供一个可用的实现，再来持续优化其性能。但是，在数据库层内建JSON解析器时处理JSON最快的手段。你可以使用CRL类型或者CLR解析器作为外部库但是它的性能不会比原生代码解析JSON更快。