MS SQL Spatial作为中央数据存储区？

我一直在努力将我们的空间数据从一个专有系统中打开，以供更多产品（MapGuide，ESRI，gvSIG，Map3D等）读取。

我已经决定使用SQL Spatial，因为我们有内部可用的服务器，并且可以通过它轻松地链接到其他系统。

在我全力以赴将其用作中央数据存储之前，有什么我应该意识到的事情会大大降低性能吗？

我的答案与性能无关，但是请注意，您仅限于“简单功能”和有限的Spatial SQL查询集。尽管我很快就发现自己想要一些Postgres或Oracle中可用的SQL查询，但这并不是一件坏事。我实际上喜欢的简单功能（保持简单）使您可以遵循良好的数据库惯例，并可以将数据转换为线，面，关系以及所需的任何内容。

使用Multi-grid索引而不是R-Tree作为PostGIS和Oracle。

与性能无关，但可能很重要：

不支持坐标转换。

SQL语法略有不同。例：

SELECT * FROM table1 WHERE the_geom.STIntersects(geometry::STGeomFromText('POINT(100 100)',0));

可能还有更多，但目前我不记得他们了:)

一些负面因素：

• 正如Mario提到的，没有内置的投影工具意味着需要额外的软件（FME或GDAL有用）来重新投影数据

• 某些空间查询（相交处/内部）缺乏性能，并且必须手动创建空间索引，尽管在下一Denali版本中，性能和“自动”空间索引显然有了巨大的改进

• 没有线性引用（但可以与.NET代码一起添加-参见下文）

• 缺乏社会的-有一个相关的开源项目在http://sqlspatialtools.codeplex.com/很少活动，这样的驱动程序和工具，在微软发布的摆布。没有太多的SQL示例。

• MapServer和GDAL现在都具有SQL Server 2008驱动程序，但它们只是在最近才出现-比其他空间数据库晚了几年。

从积极的一面：

• 与.NET集成。由于SQL Server允许.NET代码在它允许funcitonality在.NET的DLL和库的数据库中运行要包含在视图，存储过程，触发器等图书馆等http://projnet.codeplex.com/可包括在内以允许在数据库中进行重新投影。

• 专有系统都包括SQL Server驱动程序/加载程序等。

• 许多组织已经拥有SQL Server DBA，服务器，备份过程

• SQL Server Management Studio是一个非常不错的工具，并且包括空间可视化

• OGC关于空间方法和简单特征的标准

如果您的数据以地理类型在全球范围内存储，则需要注意“ 半球限制”。