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很好地概述了为什么它很重要。