如果您有任何共享数据,postgresql’s “schema” is similar to what mysql calls a “database”.您可以创建SCHEMA clienta; CREATE TABLE clienta.customer(…);.您将为每个客户端创建一个模式,该客户端的用户将首先在其搜索路径中拥有其模式,并且将授予权限,以便客户端A的用户可以访问客户端和公共模式(及其表).

您的问题将是在客户端的高端,每个表都存储为一个文件,因此,无论您是每个客户端使用一个数据库,每个客户端使用一个模式,还是使用${client} _customer等等表名,即使每个客户端只有一个表(每个连接加一个文件描述符),您可能会有1000个客户端run into filedescriptor limits.当然,您可以使用sysctl动态调整内核的最大文件描述符数,但如果您在第一次将其设置得太低,则每进程限制(ulimit)将需要重新启动postgresql.

另一种方法是使用“一个大表”和一个客户端列来标识该行所属的客户端(理想情况下,如果每个客户端有一个用户,则通过用户名,这使得下面的内容更容易).通过不授予客户端对此表的任何访问权限,您可以创建特定于客户端的视图(或使用session_user来标识当前客户端).但是,更新不能直接通过视图完成.您需要在表上插入/更新/删除已定义的函数(每个客户端使用一组函数或使用session_user),使用SECURITY DEFINER执行的函数作为特殊用户执行,并具有插入/更新/删除的权限.表(注意：使用session_user是因为user和current_user基于当前上下文,并且在SECURITY DEFINER函数中,这将始终是定义函数的用户).

性能方面,除了fd问题之外,我老实说不知道postgresql中10000个数据库会发生什么,而不是一个大表,其中包含10000个客户端的数据.正确的索引设计应该使大表不会慢于查询.

我会说我在这里为每个客户端安装了单独的数据库(我们添加服务器以保持系统可用,根据需要将客户端数据库转移到新服务器,因此我们永远不会在一台服务器上获得10k数据库).我不得不从备份中恢复单个客户端的数据以进行调试,或者由于用户错误而定期恢复,这对于“一个大桌面”设计来说是绝对的噩梦.此外,如果您打算向您的客户销售产品的定制,那么“一大表”设计可能会最终阻碍您定制数据模型的能力.