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

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

评论

您在谈论哪种“类型”?是多边形,线和点吗?还是“道路”,“河流”等类型?

我的意思是几何类型,例如“多边形”,“线”和“点”。

#1 楼

如果您不需要第三方支持并且不预见需要通过类型查询来将它们保存在同一表中就可以了。或者,您可以使用PostGIS in Action第3章中讨论的继承模型。我真的不在乎查询中是否使用了多种不同的类型。如果它在Oracle中对您来说效果不错,那么在PostGIS中的性能似乎就不会更好。 > 1)防止人们插入您不想要的其他类型,例如几何图形集合,圆弧串以及不想要的其他类型(您可以手动定义约束)

2)如果您有十亿个点,并且1000个多边形,并且在多边形测试中做了很多工作,如果查询并进行联接(相对于十亿个记录表),而不是十亿对十亿记录表,则速度要好得多。我认为任何空间数据库(并非特定于PostGIS)都是这种情况。我猜想的所有关系查询都是如此(并非特定于空间查询)。

评论


为了使人们重新回到现在的利益:在PostGIS in Action 2nd Edition中,该内容移至第14章。

–yeedle
17年8月18日在18:09

#2 楼

这个真的困扰我。我想这是因为我看到了太多的CAD文件,其中的数据全部都在一层上,仅按颜色进行区分。属性。

基于这种选择,我总是会通过数据结构来组织数据。

首先,在处理数据时,您要跳过的环要少一些(例如,从id = X的表中选择a,b,c,而不是从id的表中选择a,b,c = X AND lid = Y)

然后,考虑为什么数据库允许多个表-如果一种数据格式提供了特定的数据结构,则必须认为如果使用它们,它们将更有效地处理数据。 >
但是(对我而言)最大的问题是何时要将数据移入另一个系统。然后,我认为这将成为一个真正的挑战,因为最终应用程序可能不会以相同的方式使用数据。在这种情况下,我看到很多人都没遇到问题。 )数据模型。

评论


我同意您的意见,因为OP的场景可以说是肮脏的(我们不知道背景情况),但是您对此的评论有些戏剧性。这几乎不像您所描述的那样是灾难性的剧变。我不在乎它是用于日常使用还是用于ETL到新的系统/体系结构中,可以通过一些视图和一些适当的索引轻松地简化整个过程,并且可以在几分钟内完成编写。即使有几个唯一的盖子值。

– elrobis
16年11月3日在16:15