[thelist] Archive Strategy Question

Luther, Ron ron.luther at hp.com
Fri Aug 29 13:56:47 CDT 2003


Howdy 'Volters,


Even though I'm already up to my eyeballs, I had a new alligator introduced to my pond the other day ...

The Set-up:
I have a large number of web-based reports that run off some data tables that get updated several 
times a day.  The structure of the underlying data feeds will be changing so significantly that the 
current table structures can no longer be used on a 'go forward' basis.  (Yep - "merger impact".) 
New reports will have to be developed based upon the new data feeds.

What I need are some interesting ideas on how to keep those "old" reports 'live' and available to 
users who want to see the old historical information for some extended period of time.  So far the 
ideas I've come up with seem to fall into three categories.

Are there any other categories?  Anybody run into this and have a better idea?  Is there a 'conventional 
wisdom' that any of these approaches is 'the best'?


Static:
I could run each report (potentially multiple times) and dump the results to a static .csv or .xls file, 
place those on the server, and 'retire' the dynamic reports and database tables/schedules/etc.

+ Once completed this should be a very low maintenance proposition.
- Users lose the 'dynamic' functional interaction presently offered by the report apps.
- Users would be 'locked in' to whatever options I happen to chose when I generate those static 
snapshots.


Dynamic:
I could shut off the load schedules, move the tables to a new 'archive' db instance and point the current 
reports at it.

+ Low initial investment in time and effort.
+ Users retain full report functionality.
- Could easily lead to 'down the road' maintenance issues through hardware upgrades, server upgrades, 
db upgrades, and even browser upgrades.
- Licensing agreements may not allow 'perpetual use' of an old software version.


Blended:
I could create some new 'data-models', possibly in a 'cube' environment, populate them with the 
historical data, and turn the users loose in data 'mining' with whatever 'tool du jour' happens to come 
along.

+ Gives 'power users' full access to the information.
+ Probably low 'long run' maintenance effort. (Should be "future proof".)
- May create a 'barrier to entry' for less skilled users.
- Large initial investment in time and effort.


Hmmm ... maybe there is a 'fourth' option where I try to engineer some method for loading the old 
data into the new structures ... it would not be easy.

I know this isn't a 'what's wrong with my code' question -- but I think it's still 'on-topic'.


Thanks,

RonL.




More information about the thelist mailing list