在对我的一个问题发表评论之后，我正在考虑使用一个具有 X 模式的数据库是否更好，反之亦然。

我正在开发一个网络应用程序，当人们注册时，我创建（实际上）一个数据库（不，它不是一个社交网络：每个人都必须有权访问自己的数据，并且永远不会看到其他用户的数据）。这就是我在以前版本的应用程序中使用的方式（仍在
MySQL 上运行）：通过 Plesk API，对于每次注册，我都会：

1. 创建具有有限权限的数据库用户；
2. 创建一个只能由之前创建的用户和超级用户访问的数据库（用于维护）
3. 填充数据库

现在，我需要对 PostgreSQL 做同样的事情（项目正在变得成熟，而 MySQL
并不能满足所有需求）。我需要让所有数据库/模式备份独立：pg_dump两种方式都可以完美运行，对于可以配置为仅访问一个模式或一个数据库的用户也是如此。

所以，假设你是比我更有经验的 PostgreSQL 用户，你认为什么是适合我情况的最佳解决方案，为什么？使用 $x 数据库而不是 $x
模式会有性能差异吗？未来有什么解决方案会更好地维护（可靠性）？我所有的数据库/模式将 始终 具有相同的结构！

对于备份问题（使用
pg_dump），最好使用一个数据库和多个模式，一次转储所有模式：恢复将非常简单，将主转储加载到开发机器中，然后仅转储和恢复所需的模式：那里是一个额外的步骤，但是转储所有模式似乎比一个一个地转储它们更快。

2012 年更新

好吧，在过去的两年里，应用程序的结构和设计发生了很大的变化。我仍在使用“一个具有多个模式的数据库” - 方法，但是，我的应用程序 的每个版本
都有一个数据库：

Db myapp_01
    \_ my_customer_foo_schema
    \_ my_customer_bar_schema
Db myapp_02
    \_ my_customer_foo_schema
    \_ my_customer_bar_schema

对于备份，我定期转储每个数据库，然后将备份移动到开发服务器上。我也在使用 PITR/WAL 备份，但正如我之前所说，我不可能一次恢复 所有数据库
。所以它可能会在今年被解雇（在我的情况下不是最好的方法）。

从现在开始，one-db-many-schema 方法对我来说效果很好，即使应用程序结构完全改变了。我几乎忘记了：我所有的数据库/模式将 始终
具有相同的结构！现在，每个模式都有自己的结构，可以根据用户数据流动态变化。