东山絮柳仔 阅读(32) 评论(0)

关键字: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查看了。

 

 

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