所以这就是我想要完成的事情。我在两个表中有坐标数据，我试图将它们与关联表链接在一起。这是一对一的关联，所以如果我在表 A 中有 40 条记录，在表 B 中有 40 条记录，那么我应该在关联表中有 40 条记录。
现在这两个表中的数据大致相同，但绝不相同，实际上它们甚至很少具有相同的精度。一个表（我们会说 A）总是有 6 个小数位，而表 B 可能没有小数位或最多 6 个小数位。
因此，假设我们只是将表 A 中的一对数据与表 B 中的 12.345678 与 12.34 进行匹配。
所以我在我的 asp.net 代码中有一个 foreach，它强制将零放在表 B 数据的末尾，所以我们首先将 12.345678 与 12.340000 进行比较。
然后是 12.34567 对 12.34000。然后 12.3456 反对，12.3400 然后 12.345 反对，12.340
然后是 12.34，反对，12.34。
只要关联记录不存在，包含对表 A 中的 12.345678 或表 B 中的 12.34 的引用，就会创建一个新的关联记录。
现在您可能会问，Joe，那么您如何比较表 A 中的数据和表 B 中的数据？我最后保存了这部分，因为它是最奇怪的。
我正在使用 LIKE，我相信这会让一些人感到不安，因为你已经在想，“你到底为什么要使用 LIKE，它是用于浮点数的字符串匹配？”
好吧，因为它目前为止效果最好，大约 95% 的时间。其他 5% 的大部分只是因为数据差异太大，但有一个非常奇怪的子集绝对应该匹配。
因此，在插入记录之前，我会检查匹配项，只要我只有一个匹配项，我就会创建关联记录。
SELECT COUNT(*) FROM dbo.StartCoord
WHERE StartLatitude LIKE '12.817%'
AND StartLongitude LIKE '12.819%'
现在我正在查看 12.817 和 12.819 的来源记录，完整值实际上是 12.8179 和 12.8199。所以它应该有效，并且在 95% 的时间里它确实有效。
现在对于奇怪的部分，也许使用 LIKE（应该只用于字符串匹配）导致 SQL Server 在后台进行舍入。我上面的 stmt 不起作用，但是如果我把它扔到 Microsoft SQL Server Management 中，并将其更改为...
SELECT COUNT(*) FROM dbo.StartCoord
WHERE StartLatitude LIKE '12.817%' --trying to string match 12.8179
AND StartLongitude LIKE '12.82%' --trying to string match 12.8199
...有用！
我假设有人会说它实际上不是 LIKE，但事实上我将 LIKE '12.817%' 与浮点数进行比较并且浮点数导致 SQL Server 制定一些舍入机制。
但是，如果是这样的话，为什么 LIKE '12.817%' 会匹配原来的 12.8179？它是否应该也没有四舍五入，并且仅在 12.82 的情况下匹配？
阅读本文后，如果有人有更好的标题，我可以为将来遇到同样问题的其他人使用，那就太好了。
谢谢。
编辑：所以我完全忘记提及为什么采用这种方法。在一个表中，实际数据最多存储六个小数位，我想我一直将其用作表 A 的示例。但是，表 B 中的数据从无小数位到六位不等，有时会四舍五入，有时则不会。
So in Table A we may have 12.123456 and in somes cases, they give us Table B data that could be 12.1234 or sometimes it could be 12.1235. How they give us data is not consistent, which is why I am working around it this way. Using rounding or casting(numeric) to handle both of these cases results in less Associations being created, but I've only started experimenting with that. I also found a STR() function I am interested to look at.