答案 0 :(得分：18)
我在谷歌搜索中看过人 关于模式分开 每个在线客户的架构+表格 到他们的网站。他们喜欢 100,000个模式。 Q3：我错过了什么 这里？这似乎是极端的说法 最小。他们应该添加记录 到每个客户的标准表 不为每个制作模式和表格 顾客。
每个租户（客户）的一个数据库易于构建，它为您提供最大的租户隔离和最简单的灾难恢复。但它相对昂贵。
每个租户一个架构也很容易构建。租户之间的隔离程度较小。 dbms可以为每个服务器支持更多租户，每个租户使用一个模式，而每个租户使用一个数据库。一个租户的灾难恢复比每个租户一个数据库更复杂。
共享架构要求每一行都有一个租户标识符。硬件和备份更便宜;一个租户的灾难恢复可能是一个真正的婊子。 （要恢复单个租户的数据，您必须在每个表中恢复一些行。当发生这种情况时，性能会受到所有租户的影响。）隔离比较棘手。由于租户共享表，确保没有租户可以访问其他租户数据比使用一个数据库或每个租户一个模式要困难得多。
这个东西的搜索词是“多租户数据库设计”。所以也有一个multi-tenant标签。
另一个常见用途是将属于一起的数据库对象分组。例如，如果您正在开发会计数据库，则实现“应付帐款”功能的所有对象可能都在“ap”架构中。我也使用模式进行PostgreSQL扩展。在我的数据库中，我在“hst”模式中安装了hstore扩展，在“tbf”模式中安装了tablefunc扩展，等等。
答案 1 :(得分：7)
这是我见过的另一种常见用法。模式和search_path允许两个或更多开发人员在不需要自己的副本的情况下处理大型数据库的同一个副本，但不会相互影响。
假设Joe正在撰写评论表，Jim正在研究工作流程表。他们都需要用户，组等表。 Joe创建了一个模式，创建了自己的评论表工作版本，可以随意使用它：
create schema joe;
create table joe.comments (rest of new tabledef here);
set search_path='joe','public';
现在当Joe在alter table表上执行joe.comments时，Jim看不到任何更改，并且他的开发不会受到损坏的joe.comments表等的影响。当Joe的代码有一个search_path 'joe','public'运行，它看到了joe的评论表，而其他人都看到了原始的。
经过彻底的测试，Joe的评论表基本上可以一举代替原版，而不会中断Jim的开发。这次乘以40个开发人员，它允许所有40个人在相同的开发数据库上工作而不会相互吹嘘（或者至少不那么频繁）。
答案 2 :(得分：7)
架构本质上是命名空间。它们在命名空间在编程中有用的相同情况下很有用：你有许多东西，很多你想要将它们分成不同的子集合（很多 - 但是少于（比如说）10,000个这样的子集合集合，只要有一个级别），同时能够在它们之间互操作。使用模式可以为其他数据库对象提供更“自然”的命名标准。
顺便说一句，名称空间的价值也不受新程序员的欢迎。事实证明，允许多个对象具有相同名称这看似微不足道的好处并非如此微不足道。只有当一个人在大型项目上工作了一段时间（有数千个“代码对象”：表，视图，索引，存储过程，域等）时，人们就会明白命名空间的好处超过了它们的成本。 / p>
在较早的时代（而不是PostgreSQL），我在一个拥有大约20个客户的计算机局工作，从DBMS的250个并发用户到一个，每个通过私人租用的电话线。 （这是在互联网之前。）每个客户都有自己的架构，管理员用户（角色）可以在员工来去时创建和删除其他用户，授予和撤销权限，并执行有限的数据定义工作和以自己的架构导入/导出。作为开发人员，我不得不使用模式，因为只有一个DBMS实例和一个数据库。所以......如果上述内容不具说服力，你可以说模式符合SQL标准（由于历史原因），因此PostgreSQL支持模式。
今天，在实验室环境中可能会出现一些类似于我的情况，其中一些研究人员（或数百名学生）每个人都希望在访问公共模式中的公共集合时处理他们自己的数据。使用模式有助于阻止事故：无意中践踏对方的数据。
答案 3 :(得分：4)
模式的主要优点是为数据库表提供逻辑分组。最可能的用例是：