我有一个保存大量数据的系统。使用的数据库是 SQL Server。其中一张表有大约 300000 行，并且有很多这种大小的表。此表会定期更新 - 我们称其为“事务数据库”，其中发生了事务。
现在，我们需要实现一个报告功能。一些架构师提出了一个不同的数据库，它是该数据库的副本+一些用于报告的附加表。他们提出这个是因为他们不想破坏事务数据库的功能。为此，必须经常将数据移至报告数据库。我的问题是，是否真的需要为此目的拥有第二个数据库？我们可以将事务数据库本身用于报告目的吗？由于必须将数据移动到不同的数据库，因此会涉及延迟，如果事务数据库本身用于报告，则不会出现这种情况。 期待一些专家的建议。
【问题讨论】：
标签： sql sql-server database architecture
您需要对 ETL、数据仓库和报告数据库进行一些研究，因为我认为您的架构师可能正在以一种很好的方式解决这个问题。由于您没有提供实际报告的详细信息，因此我将尝试回答一般情况。
（免责声明：我在这个领域工作，我们有针对此的产品）
事务性数据库已针对读取/更新/插入之间的良好平衡进行了优化，索引和表规范化也适用于此效果。
报告数据库旨在非常适合读取访问，而不是其他所有事情。这意味着将应用于事务数据库的“正常”规范化规则将不适用。事实上，可以进行高度的非规范化，以使报告查询更有效且更易于管理。
在事务数据库上运行复杂（尤其是对扩展数据范围（例如历史时间范围）的聚合）查询可能会影响性能，从而数据库的关键用户（事务生成器）可能会受到负面影响。
尽管在您的情况下可能不需要报告数据库，但您可能会发现将两个用例分开会更简单。
您对数据延迟的担忧是真实存在的。这只能由将使用报告的业务用户来回答。人们经常说“我们想要实时信息”，而事实上，如果不是所有的需求都包含在非实时信息中，那么他们的需求就会很多。可接受的数据陈旧程度只能由他们来回答
事实上，我建议您进一步研究并查看多维多维数据集来解决您的报告问题，而不仅仅是报告数据库。设计将您的报告问题抽象到全新的水平。
【讨论】：
在理想情况下，报告和运营数据应该是分开的。原因是您希望将事务表用于插入/更新（通常较少索引）和报告选择（通常更多索引）。当然，现实世界并不是完美的世界。所以这是我的经验法则。只要您可以在同一张表上同时保持报告代码的可维护性而不会降低性能，那么就没有真正的分开的理由。当是时候进行跳跃时，您可能会处于关系数据库至少应该使用 BI 解决方案来增强的阶段。当时机成熟时，这两者应该分开的另一个原因。
要记住的一件事。大多数建筑师都想超越建筑师，毕竟这是他们的工作。让他们诚实，让他们证明自己的观点。就您而言，始终希望您非常成功，以至于您需要他们所说的那样进行设计，但是如果这会花费您显着的交付速度问题，请不要尝试实施最终游戏。
【讨论】：
我赞同 Hubson 的回答。我自己可能不是一个像样的 sql server 开发人员，但我遇到过大表（大约 1m 行）。所以我或多或少有这方面的经验。
参考this SE answer，我可以说由于硬盘的 I/O 容量，同一硬盘上的多个 DB 不会提高性能。如果您能以某种方式将报告数据库放到不同的硬盘上，那么您可以通过在I/O 上使用一个硬盘密集型硬盘，在read only 上使用另一个硬盘来获得好处。
如果两个数据库存在于同一个实例中，它共享相同的 memory 和 tempdb，这对性能或降低 I/O 成本没有任何好处。
此外，300k 行并不是什么大问题，除非它与其他 3 个 300k 表连接，或者有非常复杂的查询需要数据清理等。但是如果您的 数据增长率 strong> 未来会快速增长。
在不影响操作数据库的性能影响的情况下，您可以做些什么来提高报告的性能？
正确的索引
除了需要一些存储空间外，正确的索引可以加快数据处理速度，您会惊讶于它如何加快处理速度。
适当的锁定
NoLock imho 最适合用于报告，除非您使用与数据库中的序列化策略不同的锁定策略。由未提交的事务引起的报告结果的一些偏差通常无关紧要。
汇总数据
生成汇总数据的预定过程也可用于防止重新计算以读取报告。
编辑：
那么，拥有第二个数据库有什么好处？拥有它是有益的，即使 对性能没有直接的好处。第二个数据库可用于保持事务数据库清洁并与报告活动分开。它的好处：
保留物化数据
例如，每个月产生的总利润摘要可以存储在属于该特定数据库的表中
保持报告逻辑
您可以保护特定人员的访问权限，这与事务性数据库不同
为 db 生成的文件用事务性分隔。备份/恢复（和事务分离）更容易，当你想移动到不同的硬盘时，更容易
简而言之，为这种情况添加另一个普通数据库不会在性能上带来太多好处，除非它做得正确（分离硬盘，分离服务器等）。然而，第二个数据库在可维护性方面和安全策略方面都有好处。
【讨论】：