使用多个数据库与使用单个数据库的优点/缺点答案

【问题标题】：Pros/Cons Using multiple databases vs using single database使用多个数据库与使用单个数据库的优点/缺点
【发布时间】：2013-09-25 11:20:55
【问题描述】：

我需要设计一个在 SQL 中代表多个“客户”的 Windows 应用程序服务器。每个客户都有相同的数据模型，但它是独立的。

使用多个数据库与使用单个数据库的优缺点是什么。

哪一种是完成这项工作的最佳方式。如果要使用单个数据库，该怎么做？

已编辑：

一件事是数据库将托管在云（机架空间）帐户中。

【问题讨论】：

优点：安全性。缺点：可用性。
“多个客户”是指您有网店之类的东西，需要存储客户信息吗？或者您是否为客户的应用程序（如 CRM 系统）托管数据库？
为客户的应用程序托管数据库，例如 CRM 系统。
如果它的基础架构/数据库布局基本相同，我会确保使用配置管理工具（Chef、Puppet、SaltStack、Ansible 进行自动化）——选择一个，节省您在长期）。
这是一个没人提出的论点：根据存储的数据类型不同的数据库。我可以想象这样一种情况，我将客户存储在 SQL 数据库中，他们的聊天日志存储在 NoSQL DB 中，如果我需要它们之间的复杂关系，将它们存储在图形数据库中。当然，这听起来像是一个极端的用例，但对我来说听起来很有效

标签： c# sql-server winforms rackspace-cloud

【解决方案1】：

不要将来自多个客户的数据存储在同一个数据库中——我知道一些公司不得不花费大量时间/精力/金钱来修复这个错误。我什至知道客户不愿意共享数据库计算机，即使数据库是分开的 - 从好的方面来说，这些客户通常愿意为额外的硬件付费。

仅安全问题就应该阻止您这样做。您将因此失去大量客户。
如果您有一些客户不愿意升级他们的软件，如果您共享一个数据库可能会非常困难。单独的数据库允许客户继续使用旧的数据库结构，直到他们准备好升级。
您正在人为地限制自然数据分区，该分区可以为您的解决方案提供显着的可扩展性。多个小客户仍然可以共享一个数据库服务器，他们只看到自己的数据库/目录，或者他们可以在单独的数据库服务器/实例上运行。
您使数据库设计复杂化，因为您必须区分否则会自然分离的客户数据，即必须在每个 where 子句中提供 CustomerID。
通过在所有表中包含更多行，您正在使数据库变慢。您将更快地用完数据库内存，因为 CustomerID 现在是每个索引的一部分，并且每个索引节点中可以存储的记录更少。由于失去了参考位置的固有优势，您的数据库也会变慢。
1 个客户的数据回滚可能非常困难，随着数据库的增长，甚至可能基本上不可能 - 您需要自定义过程来执行此操作，这比简单的标准备份恢复要慢得多，而且占用大量资源。
大型数据库很难及时备份/恢复，可能需要额外的硬件支出才能使其足够快。
使用数据库的应用程序将更难维护和测试。
任何错误都可能更具破坏性，因为您可能会因为一个错误而搞砸所有客户。
您可以通过将数据库强制到单个位置来防止可能的低延迟性能增强。例如，海外客户将一直使用缓慢、高延迟的网络。
您将被称为愚蠢的 DBA，或失业的 DBA，或两者兼而有之。

不过，共享数据库设计有一些优势。

公用表架构、代码表、存储过程等只需维护和存储在 1 个位置。
在某些情况下可能会降低许可成本。
一些维护更容易，尽管使用组合方法总体上几乎可以肯定更糟。
如果您的所有/大多数客户端都非常小，您可以通过不合并服务器来降低资源利用率（即成本相对较高）。您可以通过将客户与他们的许可和明确理解相结合来降低高成本，但仍然为较大的客户使用单独的数据库。在这种情况下，您绝对需要明确和坦率地与您的客户沟通。

除了服务器成本分摊之外，这仍然是一个非常糟糕的主意 - 但成本也可能是一个非常重要的方面。这确实是这种方法的唯一理由 - 如果完全合理，请避免这种情况。也许你最好为你的产品多做一点改变，或者只是不能以便宜的价格支持小客户。

【讨论】：

但是每当有新客户注册时，我都必须以编程方式创建新的数据库和表。此外，它还增加了用户登录时如何为用户选择正确数据库的复杂性。

【解决方案2】：

我假设对于多个客户，您不仅要存储客户信息，还要为客户的应用程序（如 CRM 系统）托管数据库。

如果是这样，那么我绝对不会将所有内容都存储在同一个数据库中。

原因：

备份，当一位客户打电话说他需要恢复备份，因为实习生设法清理了生产数据库而不是测试数据库，您确实不想处理所有其他客户同时
安全性，即使应用程序中存在错误，它也无法获取其他客户的数据。此外，考虑一个客户是否在他们自己的安全考虑方面过于放松，并且会向系统泄露密码或诸如此类的东西，如果黑客发现了进入该客户数据库的方法，请考虑如果这还包括您托管的所有其他客户的后果.
政治，即使您可以 100% 保证不会（意外）将访问他们的数据的权限提供给其他客户，一些客户也不允许将他们的数据与其他客户混合

所以底线是：独立的数据库。

【讨论】：

【解决方案3】：

有一天，您的开发人员会搞砸一些事情，一位客户将访问另一位客户的信息。结果你会失去你的客户。仅此一项就应该告诉您，多个客户不能在一个数据库中。如果他们知道这一点，就没有人愿意成为您的客户。

如果是这种情况，我是否真的必须仔细考虑最终会发生的所有问题？答案很简单——不。您不想在同一个数据库中拥有多个客户的信息。

只有当您有多路复用器数据库来跟踪客户登录、会话等时才会发生这种情况。但客户使用和存储的数据应该在专用数据库中。

【讨论】：

【解决方案4】：

要考虑的每种方法的一些优点是：

单一数据库

来自不同服务的相关数据可以通过外键约束绑定在一起
分析提取更易于编写且执行速度更快
在发生灾难时，将平台恢复到一致状态更容易
对于被多个服务引用的数据，一个服务缓存的数据可能很快就会被另一个服务使用
管理和监控更简单、更便宜

多个数据库

维护工作、硬件问题、安全漏洞等不一定会影响整个平台
假设每个数据库都在单独的硬件上，扩展多台机器比扩展一台大型机器产生更多的性能优势

Source

【讨论】：

我还说为单独的数据库实现安全模型可能更直接（应用方面）
将多个客户信息保存在同一个数据库中 - 至少可以说是一场灾难