在一个PostGIS表中混合几何类型

我面临以下问题。我必须从Oracle数据库迁移到PostgreSQL + PostGIS。当前，所有类型的所有几何形状都存储在一个表中，并且每个记录都包含一个“盖”字段，该字段指示同一图层的要素。

使用这种方法的优缺点是什么？如果不需要将数据库与第三方软件一起使用，是否应该将数据分成多个表？空间查询的性能如何，索引对我有帮助吗？

如果您不需要第三方支持并且不希望通过类型查询来保持它们在同一张表中的需求就可以了。另外，您可以使用PostGIS in Action第3章中讨论的继承模型。

http://www.postgis.us/chapter_03_edition_1

从体系结构的角度来看，PostGIS并不真正在乎查询中是否使用了多种不同的类型。如果它在Oracle中对您来说表现不错，那么在PostGIS中的表现就好像不是更好。

拆分它有两个原因（并且可以根据需要稍后进行拆分）：1）防止人们插入您不想要的其他类型，例如几何体集合，圆形字符串等等（您可以手动定义约束） ）

2）如果您有一个十亿个点和1000个多边形，并且在多边形测试中做了很多点，那么当您查询并进行联接时（相对于十亿个）到1000条记录表，则速度要好得多。十亿到十亿的记录表。我认为任何空间数据库（并非特定于PostGIS）都是这种情况。我猜想的所有关系查询也都是如此（并非特定于空间查询）。

这个真的困扰我。我想这是因为我看到了太多的CAD文件，其中所有数据都在一层上，仅按颜色区分。

这实际上是在根据结构或属性组织数据之间进行选择。

有了这种选择，我将始终致力于通过数据结构来组织数据。

首先，在处理数据时，您需要减少一个跳动（例如，从id = X的表中选择a，b，c，而不是从id = X的表中选择a，b，c和lid = Y）

然后，考虑为什么数据库允许多个表-如果一种数据格式提供了特定的数据结构，则您必须认为如果使用它们，它们将更有效地处理数据。

但是（对我而言）最大的问题是何时要将数据移入另一个系统。然后，我认为这将成为一个真正的挑战，因为最终应用程序可能不会以相同的方式使用数据。我已经看到很多人在这种情况下无法解决。

因此-根据我的经验-当数据模型具有良好的（更深入，更结构化的）数据模型时，您将能够高效地使用和传输数据两次。