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.

  1. when transaction performance critical.
  2. when it's hard maintenance window on transactional app.
  3. if reporting needs correlate results not app, other application silos.
  4. if reports need support trending or other types of reporting best suited star schema/business intelligence environment.
  5. if reports long running.
  6. if transactional app on expensive hardware resource (cluster, mainframe, etc.)
  7. 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

Popular posts from this blog

c++ - How do I get a multi line tooltip in MFC -

asp.net - In javascript how to find the height and width -

c# - DataTable to EnumerableRowCollection -