多客户端数据库设计：按模式分离是一个好的设计吗？答案

【问题标题】：multi client database design : is separation by schema a good design?多客户端数据库设计：按模式分离是一个好的设计吗？
【发布时间】：2012-10-29 18:02:39
【问题描述】：

我正在 SQL Server 2008 R2 中设计一个多客户端数据库（想想 SAS）。在我在这个论坛上的研究中，我发现从长远来看（当性能成为问题时），使用不同的数据库分离 cient 数据是首选。

但我想知道是否在短期内（以及为了快速启动），通过在同一数据库中创建不同的模式来隔离客户特定的数据是否是个好主意？

【问题讨论】：

【解决方案1】：

我的直觉说不。您提出的方法在快速启动或短期内有何收获？
最好从头开始养成良好的习惯：使用您的架构和默认值保留更新的脚本。当另一个客户需要一个新的数据库时，您就可以开始了。更不用说您的客户端代码只需要动态地选择正确的连接而无需任何其他关注

【讨论】：

我有一个 spring/hibernate web 应用程序，所以使用一个连接字符串（指向一个数据库）对我来说更容易。此外，我可以在我的数据库中编写（非系统）存储过程以按需创建新模式，以及在从 Web 应用程序创建新客户时创建基本表等......
我不是 spring/hibernate 方面的专家，所以请原谅我的无知，但是您如何编写应用程序代码？您需要始终传递要处理的架构吗？对我来说，这将是一场噩梦。我错了吗？
是的，我每次都会传递架构信息。对我来说不是噩梦（还！），因为应用程序相对简单。我将连接 3-4 个存储过程，它们将根据我传递的模式名称获取客户特定的数据。

【解决方案2】：

这种应用程序的术语是“多租户”架构。 SO 有一个多租户标签。让它成为你的最爱之一。

多租户架构的范围从“不共享”到“共享一切”。在频谱的“无共享”端，您为每个租户构建一个数据库。在“共享一切”端，租户共享每张桌子；每行都有一个租户标识符，告诉您该行属于谁。

在这两者之间，您会发现每个租户一个架构。

有关成本、数据隔离和保护、维护和灾难恢复之间权衡的更多详细信息，请参阅this SO answer。

【讨论】：