0

中心から 5Km 離れた場所にあるすべてのポイントを見つけるという、この「ばかげた」空間クエリに気付きました。ソース テーブルは +150K 行を保持します。

ここでクエリ：

DECLARE @position geography = geography::Parse('POINT(9.123 45.123)')
DECLARE @circle geography = @position.STBuffer(5000) -- A circle of 5Km of radius

SELECT 
    g.Coordinate.STDistance(@position), g.Coordinate.Filter(@circle)
FROM 
    [DB_NAME].[SCHEMA].[TABLE] AS g WITH (nolock)
WHERE 
    g.Coordinate.Filter(@circle) = 1

奇妙なことに、WHERE条件が機能しないことに気づきました。実際、条件が 0 を返す場合でも +600 ポイントを取得します。

助言がありますか？

明確にするために、テーブルスキーマは

[DB_NAME].[SCHEMA].[TABLE](Coordinate geography NOT NULL)
4

1 に答える 1

0

公式ドキュメントには次のように記載されています。«地理インスタンスが別の地理インスタンスと交差する可能性がある場合は1を返します。この方法では、誤検知が発生する可能性があり、正確な結果はプランに依存する可能性があります。地理インスタンスの共通部分が見つからない場合は、正確な0値（真の負の戻り値）を返します。»

つまり、0は常に問題ありませんが、1は概算できます（私見では、この動作は絶対に合理的です）

ちなみに、@ Damienの観察により、私は単純に回避することができます。

DECLARE @position geography = geography::Parse('POINT(9.123 45.123)')
DECLARE @circle geography = @position.STBuffer(5000) -- A circle of 5Km of radius

SELECT * FROM
    (SELECT 
       g.Coordinate.Filter(@circle) filter, g.Coordinate Coord
        FROM [DB_NAME].[SCHEMA].[TABLE] AS g WITH (nolock)
    WHERE 
        g.Coordinate.Filter(@circle) = 1
    ) t
    WHERE t.filter = 1

それは私に«ダブルチェックパターン»秘教を思い出させます…しかしその場合それは動機が明らかです。

さらに調査できるポイントの1つは、戻り値の変換についてです。何年も前に、サーバーファームで、ブール値のtreからintへの暗黙の変換が1（0x00000001）ではなく-1（0xFFFFFFFF）になるという同様の問題に遭遇しました。 ）…COMの年齢…</ p>

于 2013-03-14T16:08:44.413 に答える