SQL空間類型的WKT轉換中的跨機器不一致問題

Question

我在跨SQL Server 2008中轉換爲空間類型的已知文本（WKT）的計算機上遇到不一致的行爲。它看起來好像數據存儲的方式相同，但是根據機器的不同，轉換回WKT的行爲會有所不同！

這裏的東西我放在一起，以確定問題：

SET NOCOUNT ON; 

DECLARE @TestTable TABLE (TestPoint GEOGRAPHY); 
INSERT INTO @TestTable(TestPoint) VALUES (geography::STGeomFromText('POINT(-124.957140999999993 39.326679)',4326)); 

DECLARE @PointAsText NVARCHAR(max); 
SELECT @PointAsText = TestPoint.STAsText() from @TestTable; 
PRINT @PointAsText; 

DECLARE @PointAsBinary BINARY(22); 
SELECT @PointAsBinary = CAST(TestPoint AS BINARY(22)) from @TestTable; 
print @PointAsBinary; 

print @@version; 

在各種機器我都可以，我看到了兩個不同的結果：

POINT（-124.95714099999999 39.326679）
0xE6100000010C1EA5129ED0A94340492A53CC413D5FC0
Microsoft SQL Server 2008 R2（SP1） - 10.50.2500.0 （X64）
        2011年6月17日0時54分03秒
       版權所有（C）在Windows NT 6.1微軟公司
       開發版（64位）（建設7601：服務包1）

或

POINT（-124.957141 39.326679）
0xE6100000010C1EA5129ED0A94340492A53CC413D5FC0
的Microsoft SQL Server 2008 R2（RTM） - 10.50.1600.1 （英特爾X86）
        2010年4月2日15時53分02秒
       版權所有（c）Microsoft Corporation
        Devel OPER版在Windows NT 6.0（內部版本6002：Service Pack 2中）（管理程序）

另一個測試案例表明，一個X64機2008 R2（RTM）給-124.95714099999999。所以，肯定表明x86與x64。

我至少有點熟悉缺乏浮點精度，但我不知道它是架構特定的。似乎使用SQL空間存儲涉及通過WKT轉換的數據。我沒有看到使用這些數據的更合適的策略嗎？

Answer 1

幾周來一直沒有活動，所以我會回答我所知道的。

我最好的理解是，只需要避免使用已知文本（WKT）。我不確定知名二進制（WKB）作爲選項。

爲了確保在數據庫中使用SqlGeography時不會丟失精度/粒度，可以在中間件或應用程序中使用SqlGeography類。這個類是可以二進制序列化的，在這方面有所幫助。

通過知名文本（WKT）保留SqlGeography類的安全性時，精度將開始褪色。只有在向用戶顯示或強制與非.NET平臺進行通信時（例如使用Web服務），最好這樣做。

Answer 2

我以前從未見過這種行爲......我也希望轉換在運行相同版本/操作系統時是完全確定性的。對於它的價值，我可以確認我在SQL Server 2008 R2（x64 10.50.2500）和SQL Azure（11.0.1831）下得到了正確的預期第一個結果POINT（-124.95714099999999 39.326679）。

我能問你檢查，你還可以得到從這些機器相同的結果，當你：

SELECT @PointAsText;

而不是：

PRINT @PointAsText;

我承認這是抓着吸管一點點，但我只是想建議一些東西來隔離，它絕對是@PointAsText的值已被舍入，而不是一些有趣的格式，PRINT可以應用...