>I'm missing your point, as I didn't mention a write intensive environment.
I'm not certain what you meant. >My first examples is father to son updates which is 50% write at worse, and >the second example is read intensive. Those are nice theoretical environments. >As the second example is not write intensive, we agree on the benefit and >there is no need to debate the second example further. Do we agree? Is it worth it in the real world, or at least the one I worked in? Most environments I worked in were write intensive. Banking, credit cards, EDI, etc. And, in those, the cost of compression was/is prohibitive. Your theoretical environments are nice, but, emprically, they did not exist for me. We had two databases that were read intensive, and compression, for them may have been worthwhile, but they didn't have much activity. They were history databases. When you do a lot of updates, compression costs. Yes. If you have your designed environment, compression may make sense. - I'm a SuperHero with neither powers, nor motivation! Kimota! ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
