我仍然不清楚我对这一举动的看法,但是我们将在几个小时内就此进行一次会议,讨论优点,缺点,最佳做法,陷阱等等…所以我正在寻找你对此的想法…好吗？是坏吗我们将从现在开始有一些问题？
欢迎任何想法,技巧或建议.谢谢
编辑
为了回应对这个问题的评论,我们使用sql Server 2005,我们实际上在谈论将同一个实例上分离的数据库移动到一个数据库中.驱动的问题是数据库完全缺乏引用完整性,因为我们的大多数应用程序需要访问诸如员工记录或分支信息之类的常见数据.
UPDATE
有几个人要求我从会议结果中更新这个问题,所以在这里.我们反复讨论了这样做的优点和缺点(我甚至用投影机向他们展示了这个问题),当我们完成这个工作的时候,我们几乎涵盖了这里的优点和缺点.大约有一半的人认为我们可以用正确的资源和承诺来完成工作,大约一半的人认为我们不能做到这一点(或者说不会很好).我们决定用微软一些时间来获得他们的想法和平台的具体建议.在我们跟他们交谈之后,我一定会更新这个问题和my blog.感谢所有的帮助和有用的答案.
解决方法
正确使用文件组将使得以前的回复引用的大多数“cons”消失：它们可以分发I / O,它们可以对您的维护计划进行清理和备份/恢复策略,它们通过脱机仅提供损坏的部分来提供可用性db崩溃的情况下.所以我会说,虽然这些“缺点”是合理的关切,但是它们可以通过适当的部署策略来缓解.尽管这些缓解行动需要一个真正的,经验丰富的掌舵人员,但是它们将超越开发人员的需求的dba的舒适区域,这是真的.
一些职业我可以快速思考：
>一致性您可以进行备份还原,以使所有数据保持一致.单独的dbs不允许这样做,因为您无法协调一致的备份集,除非您在备份期间将它们全部脱机或使其成为r / o.
>廉价高可用性：您可以部署database mirroring以实现灾难恢复和高可用性.多个数据库有问题,因为不能协调同时进行故障转移,应用程序面临着寻求每个数据库当前位置的困境.
>安全.虽然大多数其他帖子看到一个数据库更难以确保,我会说更容易确保.多数据库似乎更难以正确安全,因为每个人都做一个登录,并将其添加到该数据库db_owner组.拥有一个数据库会使事情变得更加困难(除非你最终使每个人都变得非常糟糕),但一旦你开始做正确的事情(粒度访问),那么一个数据库并不比多个dbs更难,因为你不会有复制/维护多个dbs中的一些常见组/权限.
>控制.对单个数据库而不是多个数据库(无数据访问开发人员,仅通过对模式执行权限来执行程序访问等)的应用程序数据访问将更容易实施某些策略和良好做法).
还有一些我在其他帖子中看不到的缺点：
>这将更难拉下你现在的想法
>增加以前分离的应用程序之间的耦合将强加开发限制：您不能简单地改变模式,您将不得不与其他应用程序进行协调(您可以认为这也是以前的情况,但是在地毯由单独的dbs,你是对的)
>现在分布在多个数据库日志中的日志写入将被合并到一个日志文件中.如果你的写作很重要,那可能会成为一个严重的瓶颈,迫使你为新的,统一的日志文件购买一些昂贵的快速驱动器.一般来说,这可以通过使日志驱动器被剥离的阵列跨越尽可能多的条带使其足够快(通常是raid 10)来实现.
> GAM/SGAM/PFS分配也将合并,但通过适当使用文件组也可以减轻这种分配.
