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

Question

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

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

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

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

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

Answer 1

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

正确使用文件组将消除之前回复中引用的大部分“缺点”:它们可以分配 I/O，它们可以清理您的维护计划和备份/恢复策略，它们通过仅使发生崩溃时数据库的损坏部分。所以我想说，虽然这些“缺点”是合理的担忧，但可以通过适当的部署策略来减轻它们。确实，这些缓解措施需要真正的、经验丰富的 dba 来 Helm ，因为它们将超出开发人员根据需要转为 dba 的舒适区。

我能很快想到的一些优点:

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

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

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