Postgresql 是使用UNION ALL从多个表中提取行，还是在生产中使用一个表？

我知道对于像Postgresql这样的关系数据库，使用分离表会更有效，但我担心的是性能问题，因为执行最多的查询将使用

UNION ALL

从多个表中获取行

我不得不选择处理这个问题。第一个是：

table1 -> column1, column2
table2 -> column1, column2
table3 -> column1, column2, column3

在这个解决方案中，我必须在生产中使用3个不同的查询与

UNION ALL

合并，该查询将由登录系统的用户执行（系统中执行次数最多的查询）

另一个是：

table -> column1, column2, typeColumn, extraColumnForTable3

在这个解决方案中，我必须创建一个额外的列

typeColumn

，以区分行的类型。我还必须为类型

table3

创建一个列

extraColumnForTable3

，对于

table2

和

table1

类型，它将为空。在此解决方案中，执行最多的查询将只包含一条

SELECT

语句

---

生产中将有数百万行，因此我关心性能

NULL

值可能会占用数据库中的额外空间，但我认为它可以忽略不计。我将使用部分索引来消除空值，因此我认为它不会影响其他获取特定类型的查询。你认为哪一个在生产中更有效？

一般来说，我发现大量使用

联合

表明数据库设计不好。有些情况下，

UNION

和

UNION-ALL

是有意义的，但在递归公共表表达式之外，它们应该相对较少

PostgreSQL提供了相当多的选项来保持单个表的性能可管理，正如您所指出的，部分索引是管理此问题的一种非常好的方法

将表分解成这样的

UNION

语句的主要问题是，这样做会使主键和外键管理变得非常困难。一般来说，首先确保数据结构清晰且易于管理，然后再考虑优化比先考虑优化再设法使优化解决方案易于管理要好得多

“分开的桌子”？分离是一个结果。如果执行次数最多的查询执行该联合，则很可能您的数据结构在传统意义上没有规范化，而是只有表示同一事物的专门化的表，而不是一个表示泛型的表，然后是包含泛型中该行引用的专门化。