When to build a separate reporting database? -
we're building application has database (yeah, pretty exciting huh :). database transactional (to support app) , bit of "reporting" part of app - nothing strenuous.
above , beyond have reporting requirements - they're pretty vague , high-level @ moment. have standard reporting tool we-use in-house we'll use "heavier" reporting requirements solidify.
my question is: how know when separate database reporting required?
what sort of questions need asked? sort of things make decide separate reporting database necessary?
in general, more mission critical transactional app , more sophisticated reporting requirements, more splitting makes sense.
- when transaction performance critical.
- when it's hard maintenance window on transactional app.
- if reporting needs correlate results not app, other application silos.
- if reports need support trending or other types of reporting best suited star schema/business intelligence environment.
- if reports long running.
- if transactional app on expensive hardware resource (cluster, mainframe, etc.)
- if need data cleansing/extract-transform-load operations on transactional data (e.g., state names canonical state abbreviations).
it adds non-trivial complexity, imo, there has reason split.
Comments
Post a Comment