PostgreSQL 数据库中的对象分组答案

【问题标题】：Grouping objecs in PostgreSQL databasePostgreSQL 数据库中的对象分组
【发布时间】：2012-08-24 01:54:13
【问题描述】：

我继承了一个带有大型 Postgres 数据库的项目（超过 150 个表、超过 200 个自定义类型、近 1000 个函数、触发器等）。不幸的是，所有内容都被转储到一个模式中 (public)。从应用程序的角度来看，它工作得很好，但是维护起来却是一场噩梦。

显而易见的事情是按功能将这些对象拆分为单独的模式（例如，所有与供应商相关的东西都进入 supplier 模式，所有与管理相关的东西都进入 admin 模式等）。一旦完成，当然，需要对代码进行一些更改（好的，很多更改）才能引用新模式。考虑到 Web 应用程序包含大约 2000 个 php 文件，这可能是一项艰巨的任务。同样，由于系统中的每个 php 都已经以 require_once('controller/config.php'); 开头，我可以在那里添加一个调用来设置搜索路径以包含所有新模式：SET search_path = 'public, supplier, admin, ...'，但不知何故我下意识地不喜欢这个解决方案。

有没有其他方法来处理问题？我不想在重组数据库上花费比绝对必要更多的精力。我也几乎不会在主网站上造成任何停机，因为它被世界各地（澳大利亚、欧洲、北美）的客户使用。

你会推荐我做什么？

【问题讨论】：

诚实吗？我建议你别管它。是的，它没有按照您喜欢的方式组织，但它有效，仅此一项就很重要。想象一下，如果您将可能花费在此任务上的所有时间都花在了此任务上，并添加了新功能或修复了系统中的实际错误，而不是根据自己的喜好重新组织事物。时间很重要，这种改变只会让你更开心，你的客户会忘记，如果你想赚到钱，让你的客户开心。
search_path 是你的朋友。有a number of ways how to make use of it。
欧文非常正确。使用 search_path 是一件好事而不是避免。
您不需要在每个页面上运行 set search_path。只需执行 alter user 即可永久更改该用户的 search_path。

标签： postgresql schema grouping

【解决方案1】：

我认为search_path 方法将是您走这条路时必须采用的方法。为什么你下意识地不喜欢解决方案？如果你能克服它，它似乎会消除维护的噩梦。维护噩梦和search_path 使用哪个更糟糕？

根据docs：

将数据库对象组织成逻辑组以使它们更易于管理。

【讨论】：

如果我知道我为什么不喜欢它，就不会再下意识的了，不是吗？
好吧.. 潜意识不是我所知道的任何科学发现过程的一部分。忽略它，继续手头的事实。

【解决方案2】：

我可以理解不喜欢搜索路径的解决方案。但是您知道 search_path 可以为每个用户或每个数据库设置吗？您可以 ALTER DATABASE SET search_path 然后就完成了，更好的是它不是影响其他人的全局更改。

http://www.postgresql.org/docs/9.1/static/config-setting.html

请记住，每个用户的设置是集群全局的，并且会覆盖每个数据库的设置。

【讨论】：