PostgreSQL 9.6 查看性能和副作用

Question

我们的项目使用不同的模式来保持事物的有序性和安全性。我们GRANT 访问整个模式，而不是选择可能导致意外泄漏数据的单个组件。此外，如果我们可以从单个模式编写查询，这将使我们的生活更轻松，因为它有助于可维护性和减少错误。

例如，schema_foo 和 schema_bar 包含原始规范化数据（最终用户无法访问），schema_baz 包含从 schema_foo 和 schema_bar 返回数据的函数（最终用户可以访问）。当schema_foo 和schema_bar 中的数据需要在交付给最终用户之前进行处理时，这是有道理的；但是，在某些情况下不需要额外的处理。

在这种情况下，在schema_baz 中创建视图是否有意义，只需调用schema_foo 或schema_bar 中的表，如果是这样，两者之间的性能差异/副作用是什么

SELECT * FROM schema_foo.table_bin;

和

CREATE VIEW schema_baz.view_bin AS SELECT * FROM schema_foo.table_bin;
SELECT * schema_baz.view_bin;

如果这是可以接受的，那么（出于任何原因）按名称而不是 * 来识别每一列是否更好？

注意：生成的视图也将用于其他查询。我知道查询计划器很棒；但是，我担心 (ab) 仅出于使表可从另一个模式访问的目的而使用视图可能会产生意想不到的后果。

Answer 1

我的经验倾向于“如有疑问，请明确表示”。在生产系统中使用select * 通常只是自找麻烦。

此外，在 Postgres 中向基表添加列不会改变视图中的列——它们不会神奇地出现。举个例子：

(postgres@lh:5432) # create table foo (col1 integer, col2 text);
CREATE TABLE

(postgres@lh:5432) # create view bar as select * from foo;
CREATE VIEW

(postgres@lh:5432) # alter table foo add col3 date;
ALTER TABLE

(postgres@lh:5432) # insert into foo values (1, 'One', current_date);
INSERT 0 1

(postgres@lh:5432) [~] # select * from foo;
 col1 | col2 |    col3    
------+------+------------
    1 | One  | 2017-08-17
(1 row)

(postgres@lh:5432) # select * from bar;
 col1 | col2 
------+------
    1 | One
(1 row)

这是 9.5 版，但如果其他版本的工作方式有所不同，我会感到惊讶。

Answer 2

是的，表格可以而且确实经常发生变化。如果您只是写 *，那么如果在基表中添加或删除列怎么办？您的观点会在您不知情的情况下发生变化。

最佳做法是在编写任何类型的视图时始终列出列名。