關鍵字：SQL Server NEWID（）；BSON；MongoDB UUID 1.遇到的問題和困惑 SQL Server中的NEWID數據存儲到MongoDB中會是什麼樣子呢？發現不能簡單的通過此數據查詢了。 例如我們將SQL Server 資料庫中的QQStatements2019表遷移至Mo ...
關鍵字：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查看了。
本文版權歸作者所有，未經作者同意不得轉載,謝謝配合！！！
