Answers:
我认为空间数据库应该与传统数据库没有区别。他们本质上是在做同样的事情,存储大量数据以便快速检索。例如,在PostgreSQL / PostGIS中,几何只是另一种数据类型。就像文本或整数一样。在SQL Server 2008中相同。在Oracle中相同。如果“空间”部分只是数据库中的另一种字段类型,那么它真的与原始数据库有什么不同吗?这是否意味着我们应该抛弃传统数据库设计的所有规则?
显然,与传统数据库一样,规范化也可能做得太过分,因此要找到适合您需求的最佳设计是一个折衷的选择。
如果您打算创建一个高度标准化的结构(包含100列的表格),那么您必须问自己,未来可能会发生什么变化?随着行的大量增加,这还会影响查询性能吗?这会影响将来的可维护性吗?
创建标准化结构并使用视图将所有数据公开给数据库客户端(无论是GIS还是任何其他客户端)有什么问题?
所有这些问题都适用于传统数据库和空间数据库。如果您浏览http://en.wikipedia.org/wiki/Database_normalization,您会发现它也适用于空间数据库。
如果您在数据库之上使用的软件迫使您使用高度非规范化的结构,则这是一个不同的论点。您受软件而不是数据库的约束,因此您没有最佳数据库设计的选择。
所以我认为,简短的答案是(在我看来)数据库设计对于空间数据库与传统数据库同样重要。
我经常看到这一点。我觉得这是由于传统的GIS人员来自调查背景而没有数据库的背景/知识这一事实。但是,随着越来越多的组织将GIS基础架构移至IT部门,我看到了这一变化。
GIS软件旧版
以前的ArcSDE成本高昂,SQL Server中缺少空间数据类型(直到2008年),而Oracle直到版本10为止,这意味着除了将数据存储在shapefile中之外,对于许多组织而言别无选择(并且通过投标人降低投标成本) 。
SQL Server中本机空间类型的引入几乎立刻意味着ArcSDE从一笔巨额投资变成了免费包含在ArcGIS中,以及组织中的空间数据“引入”。
使用ArcGIS和SQL Server的组织以前有三个选择:
一旦SQL Server具有本机空间类型,大多数供应商就会使用此空间类型而不是其专有格式,这意味着空间数据可能会突然被其他应用程序访问。ESRI必须降低ArcSDE的成本(通过将其集成到ArcGIS中来实现)和/或允许将空间数据以本机数据库格式存储。
另外,在ArcIMS中对shapefile进行的查询意味着与DBF相关联,因此必须包括所有必填字段和重复项,因为无法选择创建空间视图或轻松将要素与后端数据库链接。
组织原因
我同意其他人的观点,即直到最近空间数据成为本机数据库类型,长期以来,组织中的数据库管理员一直忽略或将其分开,并成为GIS经理的职责。数据库设计,规范化,复制,安全性和SQL视图的概念通常需要非常不同且专业的技能,并且在学习过程中不容易学习。
费用原因
用招标的方式解释在数据模型上花费大量时间和精力的要求,并且清理/导入数据到该模型中通常是不可能的。通常,项目购买者来自GIS的分析视角,却忽略了结构化数据的重要性。
通过100列表,我假设您的意思是从构建多个输入的“主覆盖”覆盖图获得的输出类型。是的,这些是Arc / INFO工作流程的工件。但是,在防御方面,您也可以将它们视为OLAP的故意非规范化表。由于它们主要用于查询处理,而不是用于数据更新,因此非规范化形式具有一定意义。就像一个星型模式,但没有点。好的,淡茶,但我仍然认为那里有东西。
是的,如果开始新的GI项目设计很重要,并且可以节省时间=将来节省金钱。 http://www.amazon.com/Spatial-Database-Systems-Implementation-Management/dp/1402053916很好地概述了为什么它很重要。