使用单个数据库有哪些优缺点和最佳实践？

Question

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

我仍然不确定我对此举的看法，但我们即将在几个小时内召开会议，讨论利弊，最佳做法，陷阱等......所以我'我在寻找你的想法......这样好吗？这不好吗？从现在起一年后我们会遇到什么问题？

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

修改 在回答对这个问题的评论时，我们正在使用SQL Server 2005，我们实际上正在讨论将同一个实例上的单独数据库移动到单个数据库中。驱动问题是数据库中完全缺乏引用完整性，因为我们的大多数应用程序需要访问公共数据，例如员工记录或分支信息。

更新 有几个人要求我用我们会议的结果更新这个问题，所以在这里。我们来回讨论了这样做的优点和缺点（我甚至用投影仪向他们展示了这个问题），当我们完成时，我们几乎涵盖了这里所包含的优点和缺点。我们大约有一半的人认为我们可以用合适的资源和承诺来完成它，大约一半人认为我们做不到（或者它不会很好）。我们决定利用微软的时间来获取他们的想法和平台特定的建议。在我们与他们交谈之后，我一定会更新这个问题和my blog。感谢所有帮助和有用的答案。

Answer 1

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

正确使用文件组将使之前回复中引用的大多数“缺点”消失：他们可以分发I / O，他们可以清理您的维护计划和备份/恢复策略，他们只通过离线提供可用性在崩溃的情况下db的损坏部分。所以我要说，虽然这些“缺点”是合法的问题，但可以通过适当的部署策略来缓解这些问题。尽管这些缓解措施需要真正的，有经验的dba掌舵，因为它们将超出开发人员的舒适区域，因此需要这样做才是真实的。

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

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

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

1. 你现在想的事情要难得多了
2. 增加以前分离的应用程序之间的耦合会产生开发限制：你不能简单地改变你的架构，你将不得不与其他应用程序协调它（你可以说这也是以前的情况，但是被刷了通过单独的dbs在地毯下，你是对的）
3. 现在分布在多个数据库日志中的日志写入将合并到一个日志文件中。如果您的写入很重要，这可能会成为一个严重的瓶颈，迫使您为新的，整合的日志文件购买一些昂贵的快速驱动器。一般来说，这可以通过使日志驱动器成为一个剥离的阵列来跨越所需数量的条带以使其足够快（通常是raid 10）。
4. GAM/SGAM/PFS分配也将合并，但同样可以通过正确使用文件组来缓解这种情况。

Answer 2

优点：

• 您只需要记住一个连接字符串
• 当用户报告访问速度很慢时，您知道哪个数据库导致了问题

缺点：

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

Answer 3

我能想到的唯一“Pro”是你的所有系统都在一个数据库中，因此备份，存储等一个地方。但是，我认为这也是最大的一个“缺点。”

其他一般缺点：

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

Answer 4

听起来好像你的公司在使用数据库技术的两个完全不同的动机之间转换。首先是应用程序支持。第二是数据集成。如果我对此是对的，那么这个过程将会开辟出大量的蠕虫病毒，而且许多问题甚至无法通过将所有数据放在一个大数据库中来解决。

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

修复数据以便存在参照完整性，并修复模式以强制执行参照完整性，并修复应用程序以使应用程序与新模式一致，这将是一项艰巨的任务。

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

根据数据库管理，软件，安全性和性能要求失败而不是集成数据的需要，决定这些模式是属于一个数据库还是多个数据库。无论您使用一个平台还是多个平台，都是一个可分离的决定。

必要时，在不同的数据库中维护相同数据的同步副本。在上面的性能考虑中包括执行此操作的开销。

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

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

这并不容易。

Answer 5

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

Answer 6

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

Answer 7

优点：

• 将所有东西放在一个地方的便利
• 少考虑良好的数据库设计

缺点：

• 甚至不相关的东西都在一个地方
• 少考虑良好的数据库设计导致数据标准化不佳

对我而言，这听起来像懒惰，并且相信所有这些“花哨的象牙塔数据库的东西”都毫无价值。

Answer 8

我可以看到这是可怕的，但考虑到使用Oracle EBS，SAP或其他系统的企业数量，实质上是相同的配置，我不认为它是一个坏东西™。这是一个很大的举措，并且艰难才能正确，但从长远来看，它可以真正改善整个企业的整合。

Answer 9

我从来没有听说过这种做法，想知道会议的进展情况。当数据彼此不相关时，我认为将多个应用程序组合到单个数据库中并没有什么好处。

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

Answer 10

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

您只是复制了因该数据库损坏而导致的任何问题。传播风险！

Answer 11

对于参照完整性问题，您可以在辅助数据库中创建这些共享表的副本。您无法使用真正的复制，但您所做的就是拒绝所有内容，只为大多数用户选择这些内容。

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

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

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

我希望即使是大型企业，你也只会看到几十个核心实体表。

Answer 12

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

我和其他一些有兴趣听取会议结果的人在一起。