原文地址：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更快。