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

Question

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

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

欢迎任何想法,提示或建议.谢谢

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

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

Answer 1

由于规模庞大,较大的数据库难以维护:备份需要更长时间,灾难恢复速度较慢,这反过来又需要更频繁的备份.您可以通过在维护计划中创建文件组并使用文件组级备份来解决这些问题,并且在崩溃恢复时,您可以使用" 零碎恢复 "策略来加快速度.

正确使用文件组将使之前回复中引用的大多数"缺点"消失:他们可以分发I/O,他们可以清理您的维护计划和备份/恢复策略,他们通过仅脱机损坏的部分提供可用性崩溃时的数据库.所以我要说,虽然这些"缺点"是合法的问题,但可以通过适当的部署策略来缓解这些问题.尽管这些缓解行动需要真正的,有经验的dba掌舵,因为它们将超出开发人员的舒适区域,因此需要时才是真实的.

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

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

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

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

Answer 2

优点:

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

缺点:

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