Question

所以这就是我想要实现的目标。我在两个表中协调数据，我试图用一个关联表连接在一起。它是一对一的关联，所以如果表A中有40条记录，表B中有40条记录，那么我应该在关联表中有40条记录。

现在这两个表中的数据大致相同，但从来都不相同，实际上它们甚至很少具有相同的精度。一个表（我们说A）总是有6个小数位，而表B可能没有小数位或最多6个小数位。

所以，假设我们只是匹配一对数据，比如表A中的12.345678与表B，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％'与float进行比较，而且该浮动导致SQL Server实现一些舍入机制。

但是，如果是这样的话，为什么LIKE '12 .817％'会与原来的12.8179相匹配？它是否应该没有舍入，并且仅在12.82的情况下匹配？

读完这篇文章之后，如果有人有更好的头衔，我可以在将来遇到同样问题的人使用，那就太棒了。

感谢。

编辑：所以我完全忘记提到为什么采用这种方法。在一个表中，实际真实数据最多存储六个小数位，我认为我一直用作表A示例。但是，表B中的数据从无小数位到6位有时是四舍五入的，有时不是。

因此，在表A中，我们可能有12.123456，在某些情况下，他们给我们的表B数据可能是12.1234，有时也可能是12.1235。他们如何为我们提供数据并不一致，这就是我以这种方式解决问题的原因。使用舍入或强制转换（数字）来处理这两种情况会导致创建较少的关联，但我只是开始尝试使用它。我还发现了一个我想看的STR（）函数。

Answer 1

如果您不想更改使用LIKE。你可以将float转换为小数，然后转换为nvarchar，这应该会停止舍入问题。

SELECT COUNT(*) FROM dbo.StartCoord 
WHERE CAST(CAST(StartLatitude  as DECIMAL(12,6)) as nvarchar(20)) LIKE '12.817%' 
AND   CAST(CAST(StartLongitude as DECIMAL(12,6)) as nvarchar(20)) LIKE '12.819%'

我假设您需要6个小数位。

当不需要舍入时，使用LIKE匹配浮点数

1 个答案: