我正在与一位同事合作，他建议将我们的 1 个实例数据库拆分为大约 7 个数据库（按数据域划分）用于开发和 7 个相同的数据库用于生产。我得到了测试-生产对偶逻辑，但是在什么情况下或将我们的 1 个相对简单的数据库拆分为 7 个数据库有什么优势？我们的数据仓库仅由一个商业智能应用程序使用/使用。
我很关心这个方向，所以希望你能讨论一下这个拆分的一般原因，我可以给你一个数据库当前属性的概要。
1 个数据库数据仓库：总共 352 GB，203 个表，170 个视图
建议拆分：
A: 280 GB
B: 43 GB
C: 28 GB
D: 1 GB
E,F,G: < 1 GB combined
正如您所看到的，就提议的好处而言，这已经是一个令人头疼的问题，因为存储甚至不会被远程平均分配，80% 剩余在一个数据库上。显然，按模式对数据库进行分区是不可能的（从硬件的角度来看），因为我们没有企业级 SQL Server。
拆分原因：
- 当前的数据库优化不佳，文档很少，数据类型次优，索引次佳。
我菜鸟的想法：这些问题不是和分库无关吗？它们只是需要以任何一种方式自行解决的问题。
- 当前数据库中有 372 个对象，这使得它变慢了。
我的想法：在我看来，这似乎并不大。
- 一个数据库比 7 个数据库更难记录和绘制模式图（我们将拥有跨越多个数据库的视图）。
我的想法：....这对我来说似乎完全荒谬，但也许我错了。我们已经通过 13 个“源系统”模式组织了我们的数据仓库。
- 一个数据库会导致更多的数据库死锁。
——这个问题不也和拥有多个数据库完全无关吗？据我了解，死锁发生在表级别（实际上通常甚至只是行级别，但是嗯）。即便如此，我们所有的数据插入都发生在午夜，我们在 BI 下游的所有选择都发生在凌晨 2 点。让两个进程更新同一个表与多个数据库无关，不是吗（无论哪种方式都会发生死锁）？此外，我个人没有看到在正常操作期间发生表死锁的证据。
- 数据库技术所有权/所有权。
只有我们两个人在数据库上工作。有可能他想真正隔离我们的“领地”。确实，这不是问题，但是无论如何不能在架构级别确定用户权限吗？
将数据仓库拆分为多个数据库的正当理由是什么？
很想在这里进一步了解我对一般数据库的了解。是的，我碰巧在我的知识空白处做了很多工作，但工作就是这样，我被推到了。到目前为止，东西一直很好用（敲木头）。
你绝对是在正确的轨道上！320GB 对于数据库，尤其是 DW 来说并不是很大。
这是大赚一笔。将一个组织、优化和记录不佳的大型（ish）数据库拆分为 7 个组织不良、优化和记录不佳的数据库是浪费时间！你需要从根本上解决问题！
再次，你是对的！就对象数量而言，372 非常小 - 许多大型服务器有数十个数千个。从这里
你的 370 除以 ~ 2E9 ~= 1.7E-7 - 所以不用担心这个分数！:-)
再说一次，你是对的。如果有 372 个实体之间存在相互关系，则需要记录并绘制图表。它将具有固有的复杂性。你可以做的是尝试将整个系统拆分为子系统并记录它们，然后尝试将它们融入更大的图景中——从小橡子中长出大橡树！
在多数据库场景中，您将失去的是同一架构中的 ACID 事务 - 好的，您可以进行两阶段提交，但它不如同一架构中的事务（恕我直言）健壮。如果它们对您的要求是必要的，我不确定是否有合理的理由将表格分开。
您似乎在谈论写入阻止读取？好吧，您似乎在午夜有一个批处理，然后在 02:00 有一个查询过程？如果您可以将事务/表设为只读，这将在服务器引擎处理您的数据时减轻一些负载。只有您可以判断这是否可以应用于您的场景！
当然，所有权是在表级别，根据您的服务器/版本，可以在列和/或行级别授予访问权限 - 所以所有权业务完全是红鲱鱼！如果您是执行重组的服务器 DBA（而不是简单地安排备份和其他普通任务），那么您将需要“访问所有区域”！
您应该对系统中的每个表和字段都有评论 - 您可以将“所有权”（在组织中而不是数据库意义上的事物中）放在那里 - 评论表和字段是记录系统的绝佳第一步 - 它成为自我记录！
可能有很多原因 - 有些与多租户相关（包括机器资源（CPU、RAM、HDD 和网络）和客户端机密性或要求。看看这里和谷歌“数据库多租户”或类似的.
每个人都这么说，但这是一场斗争——“文档很重要”！第一步，在评论中记录您的表格和字段。为您的所有子系统生成 ERD 图。在没有实施这些步骤的情况下，不要让任何新事物进入系统。祝你在新角色中好运！
虽然这听起来像是您的同事正在采用的经典稻草人策略，但他或她在说“拆分数据仓库”时是否意味着创建正式的数据集市？
数据仓库的两种主要方法归功于Ralph Kimball和Bill Inmon。如果您有几分钟的时间，这里有一些关于这两种常见方法之间差异的高级概述（[1]，[2] ）。
我认为可能适用于您的情况的是，Bill Inmon 的方法要求正式创建数据集市，报告工具可以从中提取数据。这些数据集市是专为特定部门或业务部门设计的，可以独占访问，我认为这可能是您的同事正在努力实现的目标。副本的相同性质很奇怪，但是以当前形式创建数据仓库的副本然后仅将特定部门的数据加载到所述副本中可能更容易？
根据您提供的内容，听起来您当前的数据仓库正在使用 Kimball 的方法，其中数据集市是您的报告工具直接访问的维度数据仓库中数据的逻辑子集。这两种设计方法各有利弊，希望您同事问题的症结在于他或她对 Inmon 的方法更满意。
希望这只是对术语的误解，与您的同事对这两种不同方法的深入讨论将有助于澄清他或她试图克服的障碍。