在对我的一个问题发表评论之后,我在想是否更好地使用带有X架构的1个数据库,反之亦然.
我的情况:我正在开发一个网络应用程序,当人们注册时,我创建(实际上)数据库(不,它不是社交网络:每个人都必须能够访问自己的数据,永远不会看到其他用户的数据).
这就是我用于我的应用程序的先前版本(仍然在mysql上运行)的方式:通过plesk api,对于每次注册,我这样做:
现在,我需要对postgresql做同样的事情(项目越来越成熟,mysql ......不能满足所有需求)
我需要使所有数据库/模式备份独立:pg_dump在两种方式下都能很好地工作,对于可以配置为仅访问1个模式或1个数据库的用户来说是相同的.
所以,假设你是比我更有经验的potgres用户,你认为对我的情况最好的解决方案是什么,为什么？
使用$ x db而不是$ x schemas会有性能差异吗？什么解决方案将来会更好地维护(可靠性)？
编辑:我差点忘了:我所有的数据库/模式将始终具有相同的结构!
Edit2:对于备份问题(使用pg_dump),使用1 db和多个模式可能更好,一次性转储所有模式:恢复将非常简单地在dev机器中加载主转储然后转储和恢复所需的模式:还有1个额外的步骤,但是倾倒所有架构似乎更快,然后逐个转储它们.
ps:对不起,如果我在文本中忘记了一些'W'字符,我的键盘会受到该按钮的影响;)
那么,应用程序的结构和设计在过去的两年中发生了很大变化.我仍在使用这种one db with many schemas方法,但是,我的应用程序的每个版本都有1个数据库:
Db myapp_01
\_ my_customer_foo_schema
\_ my_customer_bar_schema
Db myapp_02
\_ my_customer_foo_schema
\_ my_customer_bar_schema
对于备份,我定期转储每个数据库,然后在开发服务器上移动备份.
我也使用PITR/WAL备份,但正如我之前所说,它不太可能我必须立即恢复所有数据库 ..所以它可能会被解雇今年(在我的情况下不是最好的方法).
从现在开始,1-db-many-schema方法对我来说非常有效,即使应用程序结构完全改变了:
我差点忘了:我所有的数据库/模式将始终具有相同的结构!
...现在,每个模式都有自己的结构,可以改变对用户数据流的反应.