Question

假设我有一个房地产属性数据库（公寓，房屋，工业空间，办公室），每个都有一组共同属性（所有结构共有的属性，如地址，价格，描述文本，坐标，可用表面）建筑物内部，阻力框架材料类型（钢，木材，粘土：D等..）等。我应该：

1）创建表公寓，房屋，办公室等，当我执行涉及所有构造的选择查询时，使用一个视图（比如all_constr），根据公共属性从所有表中选择，然后细化基于各种标准的结果（例如，用木材制成或用（混凝土 - 钢或粘土）等制成的阻力框架。）

我并不确定视图是如何工作的，但我认为如果我做的话

     SELECT * FROM all_constr AS a  --all_constr is the view
     WHERE  a.price <50000 AND a.surface >100 ;

每次运行上述查询时，特定构建表都会迭代一次以创建虚拟表，然后再次进行过滤。这看起来效率不高。另一方面，如果虚拟桌子AKA视图存储为真实表格，那么它与案例2）几乎完全相同+如果我想看到特定于建筑物的细节我运气不好，因为没有唯一的房屋，阿普斯等的标识符我认为，一种解决方案是创建这样的视图：

     CREATE VIEW all_constr AS  
     SELECT x.common_att1, x.common_att2, x.tableoid, x.id
     FROM aps AS x
     UNION ALL  
     SELECT x.common_att1, x.common_att2, x.tableoid, x.id
     FROM houses AS x 
     UNION ALL  
     SELECT x.common_att1, x.common_att2, x.tableoid, x.id
     FROM ind_spaces AS x

2）创建另一个表（比如constr）并链接aps，这样的房子：

http://imageshack.us/photo/my-images/31/unledkwx.png/ 这样做的好处是不需要使用tableoids

那么你建议看哪种解决方案，我多次听到和阅读使用视图是一种很好的做法？

LE：如果可能的话，我希望避免使用继承，因为它太具有特定性（我不介意，只要它是最佳解决方案）

Answer 1

在PostgreSQL中，视图是rules的简写。

当查询规划器遇到规则/视图时，它会将规则中的查询片段替换为当前查询，并继续优化查询。

就像你直接从视图中输入查询一样; postgresql将优化查询，就好像根本没有视图一样，并且可以做到最有效的事情。使用视图不会影响性能。

Answer 2

将所有常见内容合并到一个表中，并在此表中添加“类型”（保留字...）列。使可选属性可以为空，或将它们放入一个或多个单独的表中。

关于数据库设计和视图的问题

2 个答案: