Postgres 9.x - 有没有办法避免将数据库连接信息硬编码到视图中？答案

【问题标题】：Postgres 9.x - Is there a way to avoid hard coding database connection info into views?Postgres 9.x - 有没有办法避免将数据库连接信息硬编码到视图中？
【发布时间】：2012-05-15 17:09:20
【问题描述】：

我经常手动将生产数据提取到我的测试数据库中，这样我就可以在真实数据上测试新代码，以及测试升级方案或重现数据特定的错误。为此，我为我的测试数据库中的每个生产表设置了一个VIEW。这些视图看起来像这样：

CREATE VIEW ProdLink.Users AS
   select * from dblink(
      'hostaddr=123.123.123.123 dbname=ProductionDB user=ROUser password=secret',
      'select * from users') as t1(userid uuid, email varchar(50), alias varchar(50), fullname varchar(50), password varchar(100));

现在，我可以在我的生产数据库上运行：

SELECT * FROM ProdLink.Users;

并查看我的生产数据库中的所有用户。然后我可以执行以下操作：

INSERT INTO Users SELECT * FROM ProdLink.Users L WHERE NOT EXISTS (select 1 from Users where Users.UserId = L.UserId);

允许我从生产中拉入测试中尚不存在的每个用户。

我有大约 30 个视图来代理生产数据，但是我发现必须将生产数据库连接信息硬编码到每个视图中有点麻烦。

我的问题：有没有避免硬编码或至少在每个视图上复制此连接信息的好方法？我可以使用数据库级变量、环境变量或其他任何东西吗？

【问题讨论】：

以这种方式将生产环境链接到开发环境通常是不好的做法。可以选择恢复备份吗？如果没有，可能还有某种类型的 etl 包来刷新一些相关数据？
@samyi - 恢复备份不会很好，因为它会清除开发数据库中的所有架构更改，或者需要我恢复然后运行某种升级脚本来带来模式和数据备份到最新（并且一些更改可能相当复杂）。当我需要从生产中快速导入一些数据时，我喜欢能够一次刷新单个表的想法。但是，我有兴趣了解为什么它被认为是不好的做法，看看这种推理是否适用于我的案例，或者它是否存在任何需要注意的问题。
这显然取决于您正在使用的系统类型，但是......性能影响和意外 ddl 脚本的可能性将是两个主要原因......即。 alter table / truncate table / etc. 在很多地方，不允许开发人员访问生产环境。我认为这完全取决于业务风险承受能力。
@samyi - 是的，最优秀的点。我觉得逻辑最适用于拥有多个开发人员和更规范的开发过程的大公司。我没有足够的数据，也没有足够的网站流量来影响性能，而且我是唯一一个参与该项目的人，所以我可能不会不小心删除一堆生产数据。不过，我确实有很好定义的用户帐户，例如我正在连接的用户无权更改任何内容，只能读取表格。

标签： sql database postgresql postgresql-9.1

【解决方案1】：

为避免重复，您可以将连接字符串存储在一个表中：

CREATE VIEW ProdLink.Users AS
    select * from dblink(
        (select conn_string from conn_string where conn = 'that_one'),
        'select * from users'
    ) as t1 (
        userid uuid, 
        email varchar(50), 
        alias varchar(50), 
        fullname varchar(50), 
        password varchar(100)
    );

【讨论】：

是的，这似乎是唯一的方法，除非您想在运行查询之前调用 dblink_connect 并设置命名连接。我希望有办法拥有服务器级变量。