Database 如何在保持标准化的同时提高ESRI/ArcGIS数据库性能？

我使用包含空间数据的数据库。这些数据库大多采用ESRI创建的专有格式，用于其ArcGIS软件。我们将数据存储在这些地理数据库中的规范化数据模型中

我们发现，在处理关系时，该数据库的性能相当慢（即，将数千条记录关联到数千条记录可能需要几分钟）

---

是否有任何方法可以在不完全扁平化/非规范化数据库的情况下提高性能，或者这受到我们使用的数据库平台的严格限制

只有一种方法：测量。尝试获取查询计划，并尝试读取它。尝试从日志文件中隔离查询，将其编辑为可执行（非参数化）表单，然后手动提交（在psql中）。试着调整一下，看看哪里疼

如果必须连接多个（大）多边形，并且它们的边界框有很大的机会重叠，几何体连接的CPU成本可能会很高。在极端情况下，您必须对其他条件（如zipcode，如果可用）进行预选，或者维护匹配记录的缓存表

编辑： 顺便问一下：你们有统计数据和自动吸尘器吗？IIRC，ESRI仍然与postgres-8.3-something联系在一起，默认情况下这些都没有运行

更新2014-12-11

---

ESRI不会干扰非gis内容。将PK/FK关系或附加索引添加到模式中完全可以。如果合适，DBMS将接收它们。ESRI将忽略它们。（ESRI只使用自己的元目录，忽略系统目录）

当我必须处理空间数据时，我倾向于预先计算值并存储它们。是的，这是一个很大的表，但是当您只在数据输入时执行一次复杂的计算时，查询速度要快得多。不过，数据输入确实需要更长的时间。我当时的情况是，我所有的空间数据都来自一个月的负荷，所以预先计算也不算太糟糕

为了确保我没听错——您正在询问如何使用您不愿透露的模式来提高专有数据库的性能。明白了。数据库格式不是我们创建的，而是ESRI创建的用于ArcGIS的格式。它是一种地理数据库格式，用于存储GIS数据。我们仅限于此，因为我们的数据是使用ArcGIS创建的，我们的软件供应商基于ArcGIS API创建软件。只有我们开发的数据库模式不能公开。我相信这对很多企业来说都是一种非常普遍的情况。所以你要求我们（你的潜在客户）帮助你处理你的秘密方案？如果我们碰巧遇到您的产品，我们仍然必须对您的“产品”进行反向工程以使其正常工作？大多数查询都是属性查询，但数据具有空间组件。我们使用ESRI文件地理数据库，并开始研究SQL Server 2008 R2上的ArcSDE。目前还不确定我们将如何向我们的软件供应商交付，这是性能成为问题的时候。ESRI支持PostgreSQL 8.4。就我个人而言，我很想安装9.1，看看它是如何工作的。PostgreSQL 9.1支持“K-最近邻索引”，即基于距离的索引。我不擅长记住版本号。不要升级到8.4以上。ESRI仍然依赖于浮点日期时间/时间戳。这是一段时间前的默认值。他们也无法提供64位二进制文件，但那是另一回事。