标签：shell使用 函数 form 数据库连接 比较 二进制 方式 返回结果 自定义协议
关键字：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查看了。
本文版权归作者所有，未经作者同意不得转载,谢谢配合！！！
SQL Server GUID 数据迁移至MongoDB后怎样查看？
标签：shell使用 函数 form 数据库连接 比较 二进制 方式 返回结果 自定义协议
原文地址：https://www.cnblogs.com/xuliuzai/p/10257695.html
