在空间索引中使用NULL

我在具有可为NULL或NOT NULL（未放置或放置在地图上）的地理坐标列的SQL Server数据库中有大量照片（〜10百万）。在空间索引中使用NULL

另外我创建了这个地理信息的空间索引。

现在我试图选择某些多边形内的所有照片。

有存储哪些不是在地图上照片的方法有两种：

如果我分配NULL地缘这不是地图上的所有照片的位置，这样的查询速度太慢的性能（如我觉得不舒服，空间索引根本不适用于NULL列）。
如果我将POINT(0 0)分配给地图上所有不在地图上的照片，性能很好，除了这个零点POINT(0 0)。此类请求也会返回错误的照片（它们在地图上不存在）。

我该如何克服这些问题？

我应该添加一个包含NULL或NOT NULL位的列，并从两列（此列和地理信息）创建索引吗？

UPDATE我试图从两列创建索引，但这是不可能的，因为空间索引只包含一个包含地理信息的列（MSDN）。

来源

2013-02-21 Ivan Kochurkin

据我所知，有我的问题的两个解决方案：

移动零点POINT(0 0)到遥远的北方点POINT(0 90)。此解决方案并不理想，但可以工作，不需要更改SQL Server版本。
通过该脚本的执行更改SQL Server版本至110（在这个版本错误与NULL被固定）： ALTER DATABASE DATABASE_NAME SET COMPATIBILITY_LEVEL = 110

来源

2013-02-28 10:02:47

您使用的是哪个版本的SQL服务器？有可空空间列的已知问题在2008年和2008 R2 请看看我的问题在这同一主题：SQL Server 2008 Performance on nullable geography column with spatial index

我具有一个单独的表来存储空间数据类型解决了这个问题。在我的项目中，我有一个地址表，里面有一个Id列，一个纬度和一个经度列然后我有一个AddressCoordinate表，它具有地址Id和一个Geography列的外键约束。最后，我有一个脚本可以在较低的基础上填充缺失的有效AddressCoordinates。

来源

2013-02-22 09:47:44 Tomas

附表不是因为冗余的一个很好的解决方案。 – 2013-02-28 09:29:11

我同意这不是一个理想的解决方案，但它确实有好处： 1：没有插入需要稍后过滤掉的虚拟数据。 2：大小和性能：虚拟数据也会显着增加索引大小，从而影响执行时间。 3：我只有存储在该表上的空间数据类型，所以唯一的重复是PK。这种折衷让我值得一看，但我知道你对你的情况得出了不同的结论。 – Tomas 2013-02-28 12:54:25

在空间索引中使用NULL

回答

相关问题