關鍵字：SQL Server NEWID（）；BSON；MongoDB UUID

1.遇到的問題和困惑

 SQL Server中的NEWID資料儲存到MongoDB中會是什麼樣子呢？發現不能簡單的通過此資料查詢了。

例如我們將SQL Server 資料庫中的QQStatements2019表遷移至MongoDB 中，集合命名也為QQStatements2019。

在SQL Server中選擇4個OrderId,資料作為演示例項，檢視如下：

經過程式轉換後，在mongodb的客戶端工具nosqlbooster上檢視。

此時沒有文件。

但是檢視文件資料量，SQL Server 和 MongoDB 二者一致，說明確實匯入成功了。

問題出在哪兒？難得資料失真了？如果是失真的話？是隻有這一個欄位失真還是全部欄位失真？

我們用這些Orderid對應的SerialNumber資料去MongoDB中查詢驗證下。

現在SQL Server資料庫中檢視，資料顯示如下：

然後去MongoDB檢視，此條件查詢竟然有資料。

但仔細檢視確實失真了，兩者顯示的不一樣。例如：SerialNumber為XX41107960HEZE的Orderid，在SQL Server中是 32C8C3A1-3444-4440-9AE4-9B7631968080，但是在MongoDB中，就變成了如下模樣，點選開啟又是另外一個樣子。

JSON Viewer的介面顯示的OrderId資料就是二進位制型別。

如上所示，MongoDB查詢顯示的資料有LUUID（），那我們在每個orderid資料上加上一個LUUID（），是不是就可以查詢到了呢？

以SQL Server 的Orderid檢視（失真前 32C8C3A1-3444-4440-9AE4-9B7631968080），沒有資料。

以MongoDB”失真”後的a1c3c832-4434-4044-9ae4-9b7631968080去檢視。

直接檢視沒有。

加上 LUUID(）檢視有了。

但驗證到這兒，還是不能根據SQL Server 中OrderID 去關聯檢視 MongoDB中的資料啊！！！

 並且仔細檢視 32C8C3A1-3444-4440-9AE4-9B7631968080（SQL Server中資料） 和 a1c3c832-4434-4044-9ae4-9b7631968080（MongoDB資料） 相似度很高。後面的幾個位元組9AE4-9B7631968080 都是一樣的。前面的幾個位元組，也都是在每個段內 以2位為單位重新排列組合。

這看著應該和資料的儲存 和型別有關，並且這個變化的只是GUID型別的”失真”了。

回頭再比較看看"失真"OrderId和沒失真的 SerialNumber在SQL Server 資料庫中是怎麼定義的。

OrderID在SQL Server資料中的資料型別是  [OrderId] [uniqueidentifier] NOT NULL，而 SerialNumber的型別如下： [SerialNumber] [varchar](50) NULL 

現在回頭去看看MongoDB儲存和SQL Server uniqueidentifier型別相關的知識。爭取從這方面找到突破口。

2. MongoDB儲存格式和SQL Server uniqueidentifier型別相關的知識

2.1 MongoDB 儲存格式

從內部講，MongoDB以二進位制JSON格式儲存文件資料或者叫BSON。BSON有相似的資料結構，但是專門為文件儲存設計。當查詢MongoDB並返回結果時，這些資料就會轉換為易於閱讀的資料格式。MongoDB Shell使用JavaScript獲取JSON格式的文件資料。所有的MongoDB驅動都執行三個主要的功能：首先，生成MongoDB物件ID。預設都儲存在所有文件的_id欄位裡。其次，驅動會把任意語言表示的文件物件轉換為BSON或者從BSON轉換回來，BSON是MongoDB使用的二進位制JSON格式。最後，使用TCP socket與資料庫連線通訊，此時使用的是MongoDB自定義協議。

所有的文件在傳送給MongoDB之前都序列化為BSON格式，以後再從BSON反序列化。驅動庫會處理底層的資料型別轉換工作。絕大部分驅動都提供了從BSON序列化的簡單介面，當讀/寫文件的時候會自動完成。二進位制資料是一個任意位元組的字串。它不能直接在shell中使用。如果要將非UTF-8字元儲存到資料庫中，二進位制資料是唯一的方式。

 2.2 SQL Server uniqueidentifier型別

uniqueidentifier 全域性唯一識別符號 (GUID)。

使用 NEWID 函式。

將字串常量轉換為如下形式（xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx，其中每個 x 是 0-9 或 a-f 範圍內的一個十六進位制的數字）。例如，6F9619FF-8B86-D011-B42D-00C04FC964FF 即為有效的 uniqueidentifier 值。 
 

3. 解決小竅門

通過以上知識瞭解，我們可能定位到資料“失真”應該和 BSON格式和驅動有關，那麼可以推測，這個工具（nosqlbooster）應該也有類似的驅動。

皇天不負苦心人，找找就找到了。

如下操作    管理設定圖示-->Display Legacy UUID in -->.NET Format

然後，執行點選檢視，結果變成了如下格式。

這個MongoDB結果中的資料和SQL Server 中的資料長的比較像了。

此時再次以SQL Server 資料庫中的一個OrderId 檢視。

此時還是沒有資料

新增CSUUID(）函式，再次檢視有資料了

 到此，我們可以鬆口氣了，總算可以，拿到 SQL Server 中的某個Order Id，也可以去轉換後的MongoDB查看了。

 本文版權歸作者所有，未經作者同意不得轉載,謝謝配合！！！