关键字：sql server newid（）；bson；mongodb uuid
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类型相关的知识。争取从这方面找到突破口。
从内部讲，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 值。
通过以上知识了解，我们可能定位到数据“失真”应该和 bson格式和驱动有关，那么可以推测，这个工具（nosqlbooster）应该也有类似的驱动。
皇天不负苦心人，找找就找到了。
如下操作 管理设置图标-->display legacy uuid in -->.net format
然后，执行点击查看，结果变成了如下格式。
这个mongodb结果中的数据和sql server 中的数据长的比较像了。
此时再次以sql server 数据库中的一个orderid 查看。
此时还是没有数据
添加csuuid(）函数，再次查看有数据了
到此，我们可以松口气了，总算可以，拿到 sql server 中的某个order id，也可以去转换后的mongodb查看了。
本文版权归作者所有，未经作者同意不得转载,谢谢配合！！！
如对本文有疑问， 点击进行留言回复！！
express+mongoose实现对mongodb增删改查操作详解
修复 Mac brew 安装 mongodb 报 Error: No available formula with the name ‘mongodb’ 问题详解
我要评论
网友评论