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查看了。

 

 

 本文版权归作者所有，未经作者同意不得转载,谢谢配合！！！