使用单一数据库的优缺点和最佳实践是什么？答案

【问题标题】：What are the pros/cons of and best practices for using a single database?使用单一数据库的优缺点和最佳实践是什么？
【发布时间】：2010-10-29 07:31:52
【问题描述】：

在工作中（一家拥有 12 人 Windows 开发团队的价值数十亿美元的制造公司），我们即将为所有新应用程序使用单个主数据库，并将其分解为我们通常拥有的模式以前有数据库。还有一些常见的模式，比如员工目录和分支目录等等......

我仍然不确定我对这一举措的感受，但我们将在几个小时后就此召开会议，讨论利弊、最佳做法、陷阱等......所以我'我正在寻找您对此的想法... 好吗？不好吗？一年后我们会遇到什么问题？

欢迎任何想法、提示或建议。谢谢

编辑在回答对此问题的评论时，我们使用的是 SQL Server 2005，实际上我们正在讨论将同一实例上的独立数据库移动到单个数据库中。驱动问题是跨数据库完全缺乏参照完整性，因为我们的大多数应用程序都需要访问通用数据，例如员工记录或分支机构信息。

更新有几个人要求我用我们会议的结果更新这个问题，所以就在这里。我们反复讨论了这样做的利弊（我什至用投影仪向他们展示了这个问题），当我们完成时，我们几乎已经涵盖了这里所涵盖的利弊。大约一半的人认为我们可以通过正确的资源和承诺来完成它，大约一半的人认为我们做不到（或者效果不佳）。我们决定花一些时间与 Microsoft 一起了解他们的想法和针对特定平台的建议。在我们与他们交谈后，我一定会更新这个问题和my blog。感谢所有帮助和有用的答案。

【问题讨论】：

你说的是什么产品？甲骨文、SQL Server？如果是 SQL Server，您是在谈论将多个实例合并到一个实例中，还是您真的在谈论使用一个数据库？此举的驱动力是什么？您的团队目前认为并希望通过这一举措解决什么问题？
编辑添加到问题以回复此评论
请在会议结束后添加更新，让我们知道哪些论点胜诉。我对这个决定的总体结果非常感兴趣。

标签： database database-design

【解决方案1】：

由于规模庞大，更大的数据库更难维护：备份需要更长的时间，灾难恢复更慢，这反过来又需要更频繁的备份。您可以通过创建文件组并在维护计划中使用filegroup level backup 来解决这些问题，在崩溃恢复时，您可以使用“piecemeal restore”策略来加快速度。

正确使用文件组将消除之前回复中提到的大部分“缺点”：它们可以分配 I/O，它们可以清理您的维护计划和备份/恢复策略，它们通过仅使在崩溃的情况下损坏分贝的部分。所以我想说，虽然这些“缺点”是合法的问题，但它们可以通过适当的部署策略来缓解。虽然这些缓解措施需要真正的、经验丰富的 dba 掌舵，但确实如此，因为它们将超出开发人员根据需要转为 dba 的舒适区。

我能很快想到的一些专业人士：

一致性。您可以进行备份恢复，以使所有数据保持一致。单独的数据库不允许这样做，因为您无法协调一组一致的备份，除非您在备份期间将它们全部脱机，或将它们设为 r/o。
非常便宜的高可用性：您可以部署database mirroring 以获得灾难恢复性和高可用性。多个数据库存在问题，因为无法协调同时进行的故障转移，并且应用面临着寻找每个数据库当前位置的困境。
安全。虽然大多数其他帖子都认为一个数据库更难保护，但我想说的是更容易保护。多个数据库似乎更难正确保护，因为每个人所做的只是登录一次并将其添加到 that 数据库 db_owner 组。拥有一个数据库会使事情变得更难（除非你最终让每个人都成为 dbo，非常糟糕）但是一旦你开始做正确的事情（粒度访问），那么一个数据库并不比多个数据库更难，实际上更容易，因为你不会有跨多个数据库复制/维护一些公共组/权限。
控制。将某些政策和良好实践强加于单个数据库而不是多个数据库会更容易（开发人员不能访问数据，应用程序数据只能通过架构上的执行权限来执行程序访问等）。

还有一些我在其他帖子中没有看到的缺点：

这将比您现在认为的更难实现
增加以前分离的应用程序之间的耦合将施加开发限制：您不能简单地更改您的架构，您必须与其他应用程序协调它（您可以争辩说这也是以前的情况，但被刷了通过拥有单独的数据库，在地毯下，你是对的）
现在分布在多个数据库日志中的日志写入将合并到一个日志文件中。如果您的写入量很大，这可能会成为一个严重的瓶颈，并迫使您为新的整合日志文件购买一些昂贵的快速驱动器。通常，可以通过使日志驱动器成为跨多个条带的剥离数组来解决此问题，以使其足够快（通常是 10 次raid）。
GAM/SGAM/PFS 分配也将被合并，但同样可以通过正确使用文件组来缓解。

【讨论】：

【解决方案2】：

优点：

你只需要记住一个连接字符串
当用户报告访问速度慢时，您就知道是哪个 DB 造成了问题

缺点：

The One DB 的备份需要很长时间，并且会随着时间的推移逐渐变长。
从备份中恢复数据将变得越来越困难。
针对一个应用的某项功能进行性能调优（SQL Profiler、执行计划估计）会降低每个应用的速度。
如果可能的话，限制对单个应用程序数据的访问是很麻烦的，这在实践中可能意味着所有开发人员和 DBA 都将获得整个王国的密钥。
新开发人员/DBA 的学习曲线要大得多，因为他们需要导航一个大型且几乎无用的（对他们而言）数据库结构，这意味着培训/升级成本更高。
当 The One 数据库出现故障时，您组织中的每个人都会玩纸牌游戏，直到它恢复为止。
为应用开发创建测试实例意味着复制整个数据库

【讨论】：

这不仅仅是如果 The One Database 出现故障，如果您丢失或损坏了一张表，您可能会发现自己必须执行完整的恢复并锁定所有其他功能才能恢复该 ONE TABLE。跨度>

【解决方案3】：

我能想到的唯一“专业”是您的所有系统都将位于一个数据库中，因此可以在一个地方进行备份、存储等。但是，我认为这也是最大的一个“缺点”。

其他一些一般的缺点：

将来将应用程序移动到不同的位置/服务器会更加困难。
如果任何应用程序使用 tempdb，可能会出现锁定问题。
在使用另一个应用程序时，一个应用程序可能会出现不相关的性能下降。
如果所有表都在同一个数据库中，则实现应用程序级安全模型会更加困难。

【讨论】：

【解决方案4】：

在我看来，您的公司似乎正在两种完全不同的使用数据库技术的动机之间转换。首先是应用支持。二是数据整合。如果我的判断是正确的，那么这个过程会带来一大堆蠕虫，而且很多问题甚至都无法通过将所有数据放在一个大数据库中来解决。

考虑您提出的两点。首先是不同数据库之间完全缺乏参照完整性。第二个是每个应用程序都有自己的模式的想法。这允许发生的是完全缺乏跨模式的引用完整性，让您回到现在的流沙中。

修复数据以实现引用完整性，修复架构以实现引用完整性，修复应用程序以使应用程序与新架构一致，这将是一项艰巨的任务。

以下是您的公司真正需要做的事情：拥有一个包含所有“企业数据”的单一概念数据库，并以强制引用完整性和实体完整性的方式进行定义。修改现有模式，使它们符合概念数据库，除了那些纯粹是该模式本地的数据和统一概念数据库中未记录的数据。在需要的地方使用约束来保证这些模式所涵盖的数据不会失去完整性。

根据数据库管理、故障软、安全性和性能要求，而不是根据集成数据的需要来决定这些模式是属于一个数据库还是多个数据库。是使用一个平台还是多个平台是一个可分离的决定。

如有必要，在不同的数据库中维护相同数据的同步副本。在上面的性能考虑中包括这样做的开销。

将概念数据库记录在 gazoo 之外。不要仅仅满足于数据形式的定义。还要坚持数据语义的定义。

请注意，如果您使用 ID 字段而不是自然键来强制引用完整性，您将不得不在一个模式中生成每个 ID 字段，并让 ID 和依赖数据之间的关联通过同义词、视图和同步传播复制。

这并不容易。

【讨论】：

【解决方案5】：

如果数据库越来越大，由于它的大小，备份变得越来越困难。

【讨论】：

【解决方案6】：

如果您想在未来添加高流量应用程序，这可能意味着严重的可扩展性问题，因为添加运行单独数据库的新数据库服务器比并行化单个数据库要容易得多。至少在 SQL Server 中。

【讨论】：

【解决方案7】：

优点：

将一切都集中在一个地方的便利
少考虑好的数据库设计

缺点：

即使是不相关的事情也都在一个地方
较少考虑良好的数据库设计会导致数据标准化不佳

对我来说，这听起来像是一种懒惰，并且相信所有这些“花哨的象牙塔数据库东西”一文不值。

【讨论】：

【解决方案8】：

我认为这很可怕，但考虑到使用 Oracle EBS、SAP 或其他本质上相同配置的系统的企业数量，我认为这不是坏事™。这是一个重大举措，很难改正，但从长远来看，它确实可以改善整个企业的集成。

【讨论】：

【解决方案9】：

我从未听说过这种方法，想知道会议进展如何。当数据彼此不相关时，我认为将多个应用程序组合到一个数据库中并没有真正的好处。

我认为，如果您决定某个应用程序在某一时刻需要它自己的数据库服务器，您可能会遇到问题。

【讨论】：

【解决方案10】：

啊，旧的 EggsInOneBasket 设计模式。这不是最喜欢的。

您只是在加剧由该数据库损坏引起的任何问题。分散风险！

【讨论】：

【解决方案11】：

对于参照完整性问题，您可以在附属数据库中制作这些共享表的副本。您不能使用真正的复制，但您所做的就是拒绝所有内容，但对大多数用户选择这些内容。

在同一台服务器上，您可以从主数据的官方存储库推送或拉取数据，并插入任何新行/更新任何更改的行。您甚至可以使用主数据库中的触发器来执行此操作（不过我不推荐这样做）。

如果是不同的实例或服务器，可以使用链接服务器或SSIS。

您可以将公共数据放入每个数据库中的“核心”架构中。然后，您可以使用工具来检查每个附属数据库中的所有核心表是否一致。可能发生的更糟糕的情况是应用程序没有看到新员工，因为核心没有更新。保持数据库分离使您能够解耦并为您提供维护窗口。（如果您的主服务器停机进行维护，您甚至可以解耦并“独立”运行）。

我预计即使在大型企业中，您也只会看到几十个这样的核心实体表。

【讨论】：

【解决方案12】：

还有许多其他方法可以解决参照完整性 (RI) 问题。我不像其他数据库那样熟悉 SQL Server。在 Informix 中，您可以使用同义词来指向其他 DB 中的对象并将它们用于您的 RI。在 Oracle 中，您可以将数据库链接到一个或多个数据库以完成相同的事情。这些方法的问题是，如果任何数据库出现故障，RI 将失败，从而导致相关数据库出现问题。选择会起作用，但插入会失败。合并可能是一个好主意，具体取决于模式的大小以及可伸缩性的其他问题。 SQL Server 存在严重的可伸缩性问题。其他数据库平台允许使用共享所有方法（Oracle 的 RAC，最新的 Informix 版本）或分区的无共享方法（DB2 的 DPF、Informix XPS、Netezza、Teradata）进行水平扩展

我和这里的其他一些人有兴趣了解你们的会议结果。

【讨论】：