SQL Server GUID 資料遷移至MongoDB後怎樣檢視?
關鍵字: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查看了。
本文版權歸作者所有,未經作者同意不得轉載,謝謝配合!!!