优点/缺点使用多个数据库与使用单个数据库
我需要设计一个代表SQL Server中多个“客户”的Windows应用程序。 每个客户都有相同的数据模型，但它是独立的。
什么是优点/缺点使用多个数据库与使用单个数据库。
哪一个是完成这项工作的最佳方式。 如果要使用单个数据库，那么将采取哪些措施。
编辑：
一件事是数据库将托管在云（rackspace）帐户中。
不要将来自多个客户的数据存储在同一个数据库中 – 我知道公司必须花费大量时间/精力/金钱来解决这个错误。 即使数据库是分开的，我甚至已经知道客户不愿共享数据库计算机 – 从好的方面来说，这些客户通常愿意为额外的硬件付费。
-
安全问题本身就会阻止你做这件事。 因此，您将失去大客户。
-
如果您有一些客户不愿意升级他们的软件，那么如果您共享一个数据库可能会非常困难。 单独的数据库允许客户继续使用旧的数据库结构，直到他们准备好升级。
-
您正在人为地限制可以为您的解决方案提供显着可伸缩性的自然数据分区。 多个小客户仍然可以共享数据库服务器，他们只看到自己的数据库/目录，或者他们可以在不同的数据库服务器/实例上运行。
-
您使数据库设计变得复杂，因为您必须区分本来会自然分离的客户数据，即必须在每个where子句上提供CustomerID。
-
通过在所有表中包含更多行，您使数据库变慢。 您将更快地耗尽数据库内存，因为CustomerID现在是每个索引的一部分，并且每个索引节点中可以存储的记录更少。 由于丧失了参考局部性的固有优势，您的数据库也会变慢。
-
对于1个客户的数据回滚可能非常困难，甚至可能在数据库增长时基本上不可能 – 您需要自定义过程来执行此操作，这比从备份进行的简单和标准还原要慢得多且资源密集。
-
大型数据库很难及时备份/恢复，可能需要额外花费在硬件上以使其足够快。
-
您使用数据库的应用程序将难以维护和测试。
-
任何错误都可能更具破坏性，因为你可以通过一个错误搞砸所有客户。
-
通过将数据库强制到单个位置，可以防止低延迟的性能增强。 例如，海外客户将始终使用缓慢，高延迟的网络。
-
您将被称为愚蠢的DBA，或失业的DBA，或两者兼而有之。
但是，共享数据库设计有一些优点。
-
公共表模式，代码表，存储过程等只需要维护并存储在一个位置。
-
在某些情况下，许可成本可能会降低。
-
一些维护更容易，但使用组合方法几乎肯定更糟糕。
-
如果所有/大多数客户端都非常小，则可以通过不组合服务器来降低资源利用率（即成本相对较高）。 您可以通过将客户端与其权限和明确的理解相结合来降低高成本，但仍然为较大的客户端使用单独的数据库。 在这种情况下，您绝对需要明确地与您的客户保持联系。
除了服务器成本分摊之外，这仍是一个非常糟糕的想法 – 但成本也是一个非常重要的方面。 这实际上是这种方法的唯一理由 – 尽管如此，尽管如此，要避免这种情况。 也许你会更好地为你的产品改变一点，或者只是不能以便宜的价格支持小客户。
我假设多个客户不仅存储客户信息，而且还为客户的应用程序（如CRM系统）托管数据库。
如果是这样，那么我绝对不会将所有内容存储在同一个数据库中。
原因：
- 备份，当一个客户打电话并说他需要恢复备份因为实习生设法清理生产数据库而不是测试数据库时，您不希望同时处理所有其他客户
- 安全性，即使应用程序中存在错误，也无法为其他客户访问数据。 另外，考虑一个客户是否在他们自己的安全考虑因素中过于放松并且泄露了密码或其他信息，如果黑客发现进入该客户数据库的方式，如果还包括您托管的所有其他客户，请考虑其后果。
- 政治方面，即使您可以100％保证不会（意外地）将数
所以底线： 单独的数据库 。
有一天，您的开发人员会搞砸一些东西，一个客户将访问另一个客户的信息。 结果会导致您失去客户。 仅这一点就应该告诉您多个客户不能在一个数据库中。 如果他们知道这一点，没有人会想成为你的客户。
如果是这种情况，我是否必须真正解决最终会发生的所有问题？ 答案很简单 – 没有。 您不希望在同一数据库中拥有多个客户的信息。
只有当您拥有多路复用器数据库以跟踪客户登录，会话等时，才会发生这种情况。但客户使用和存储的数据应位于专用数据库中。
每种方法的一些优点是：
单个数据库
- 关联来自不同服务的数据可以通过外键约束绑定在一起
- 分析提取更易于编写，执行速度更快
- 在发生灾难时，将平台恢复到一致状态会更容易
- 对于由多个服务引用的数据，一个服务缓存的数据很可能很快被另一个服务使用
- 预先管理和监控更简单，更便宜
多个数据库
- 维护工作，硬件问题，安全漏洞等不一定会影响整个平台
- 假设每个数据库都位于不同的硬件上，那么扩展多台计算机会比扩展一台大型计算机产生更多的性能优势
资源