何时建立单独的报告数据库? [英] When to build a separate reporting database?

问题描述

我们正在构建一个具有数据库的应用程序(是的，非常令人兴奋，呵呵:).数据库主要是事务性的(以支持应用程序)，并且作为应用程序的一部分也做一些报告" - 但没有什么太费力的.

We're building an application that has a database (yeah, pretty exciting huh :). The database is mainly transactional (to support the app) and also does a bit of "reporting" as part of the app - but nothing too strenuous.

除此之外，我们还有一些报告要求 - 但目前这些要求非常模糊和高级.我们有一个内部使用的标准报告工具，随着需求的巩固，我们将使用它来进行更重"的报告.

Above and beyond that we have some reporting requirements - but they're pretty vague and high-level at the moment. We have a standard reporting tool that we-use in-house which we'll use to do the "heavier" reporting as the requirements solidify.

我的问题是:您如何知道何时需要单独的数据库进行报告?

My question is: how do you know when a separate database for reporting is required?

需要问什么样的问题?什么样的事情会让您决定需要一个单独的报告数据库?

What sort of questions need to be asked? What sort of things would make you decide a separate reporting database was necessary?

推荐答案

一般来说，事务性应用程序的任务越关键，报告要求越复杂，拆分就越有意义.

In general, the more mission critical the transactional app and the more sophisticated the reporting requirements, the more splitting makes sense.

1. 当交易性能至关重要时.
2. 当交易应用程序很难获得维护窗口时.
3. 如果报告不仅需要关联来自此应用的结果，还需要关联来自其他应用孤岛的结果.
4. 如果报告需要支持最适合星型架构/商业智能环境的趋势报告或其他类型的报告.
5. 如果报告长时间运行.
6. 如果事务性应用位于昂贵的硬件资源(集群、大型机等)上
7. 如果您需要对交易数据进行数据清理/提取-转换-加载操作(例如，将状态名称转换为规范状态缩写).

它增加了非平凡的复杂性，所以imo，必须有一个很好的理由分裂.

It adds non-trivial complexity, so imo, there has to be a good reason to split.

这篇关于何时建立单独的报告数据库?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！