database - 使用单个数据库的利弊和最佳实践是什么？

在这里(一家拥有12人的Windows开发团队的数十亿美元的制造公司)在工作，我们将转到所有新应用程序的单个主数据库，并将其与通常用于数据库的架构分解在一起之前。还将出现一些带有员工目录和分支目录等内容的通用模式。

我仍然不确定我对这一举动有何看法，但是我们将在几个小时内召开一次 session ，讨论其优缺点，最佳实践，陷阱等...因此我正在寻找您对此的想法...好吗？不好吗从现在开始我们要遇到什么问题？

欢迎任何想法，技巧或建议。谢谢

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

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

最佳答案

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

正确使用文件组将使以前答复中引用的大多数“缺点”消失:它们可以分发I / O，清理您的维护计划和备份/还原策略，通过仅使损坏的部分脱机来提供可用性。在崩溃的情况下的数据库。因此，我想说，虽然这些“缺点”是合法的关注点，但可以通过适当的部署策略来缓解它们。这些缓解措施确实需要真正，经验丰富的dba掌控，这是事实，因为它们将超出需要的开发人员转变为dba的舒适范围。

我可以很快想到的一些专业人士:

一致性。您可以进行备份还原，以便所有数据保持一致。单独的数据库不允许这样做，因为您无法协调一致的备份集，除非您在备份过程中将它们全部脱机或使其变为r / o。

低廉的高可用性:您可以部署database mirroring以实现灾难恢复性和高可用性。多个数据库存在问题，因为一个数据库无法协调同时进行的故障转移，并且应用程序面临着寻找每个数据库当前位置的难题。

安全性。虽然大多数其他文章都认为更难保护一个数据库，但我想说更容易保护。多个数据库似乎很难正确地保护，因为每个人都要做一个登录并将其添加到该数据库的db_owner组。拥有一个数据库会使事情变得更困难(除非最终使每个人都变得dbo，这非常糟糕)，但是一旦开始做正确的事情(粒度访问)，那么一个数据库并不比多个数据库难，实际上更容易，因为您将不必在多个数据库之间复制/维护一些公共(public)组/权限。

控制。在单个数据库而不是多个数据库上强加某些策略和良好实践将变得更加容易(对开发人员没有数据访问权限，仅通过对模式的执行权限来强制执行过程访问等功能可以访问应用程序数据)。

在其他帖子中也没有看到一些缺点:

这将很难实现您现在认为的

以前分离的应用程序之间的增加耦合将施加开发限制:您不能简单地更改架构，必须与其他应用程序进行协调(您可以说以前也是这种情况，但是在通过拥有单独的数据库来铺地毯，你是对的)

现在分布在多个数据库日志中的

日志写入将合并到一个日志文件中。如果您写的内容很重要，那么可能会成为严重的瓶颈，并迫使您为新的合并日志文件购买一些昂贵的快速驱动器。通常，可以通过使日志驱动器跨所需数量的 strip 驱动 strip 化阵列以使其足够快(通常是RAID 10)来解决。

GAM/SGAM/PFS分配也将得到合并，但同样可以通过适当使用文件组来缓解这种情况。

关于database - 使用单个数据库的利弊和最佳实践是什么？，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/916295/