Sql Server 2016中增長了對JSON的內置支持

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