【发布时间】：2011-09-06 01:33:27
【问题描述】：
系统会生成事务记录并将它们放入 RMDB 表中，即使它们是失败的情况。将实时查询该表，并在一天结束时生成报告。
这张桌子无疑会很快变大。这是一个问题吗？如果表很大，实时查询会运行得很慢吗？有哪些解决方案？
【问题讨论】：
【发布时间】：2011-09-06 01:33:27
【问题描述】：
通常，将生产数据库兼作报告数据库并不是一个好主意。有几个原因。其中之一是，您的报表数据库架构通常与您的生产数据库相同是没有意义的。通常，出于报告性能的原因，您的报告数据库会比生产数据库更加非规范化。
另一个原因是您的报告数据库的索引要求通常与您的生产数据库不同。您的报告数据库通常比您的生产数据库有更多的索引。出于生产目的，您通常不需要那么多索引，而且您通常不需要它们。在繁重的事务系统中，大量索引会导致性能问题。
此外，通常不必在生产数据库中保留与报告数据库中一样多的数据。在我们公司，我们在生产数据库中保留了足够的数据来满足生产需求。这通常是 12 个月。在我们的报告数据库中，我们的数据可以追溯到更远的地方。此外，为了灾难恢复的目的，尽量保持生产数据库尽可能小也很重要。您的数据库越大，恢复所需的时间就越长，您离线的时间也就越长。
【讨论】：
-
好的，所以生产数据库和报告数据库应该分开。这是否意味着在一个 RMDB 系统下创建两个 DB，例如 Oracle，（对不起，我在 DB 上真的很绿）？如果是这样，当 RMDB 系统宕机时，是不是意味着两个 DB 都宕机了，您必须同时恢复它们？
-
如果可能，将生产数据库和报告数据库放在不同的服务器上，并将数据从生产复制到报告。