MySQL preps business upgrade

TalkBack 14 of 19:: Next »; « Previous

Thread View
Flat View

Data Consistency: DB designers brought up on normalization often have a problem moving to the data warehousing world. Many will obstinately continue to develop 3rd normal form solutions, and then complain about the hardware when performance dogs.

Data consistency means something very different in large historical data stores. Duplicating data in data warehousing is not a sin, but instead a primary means of bringing data related by business processes together in a data mart. Where there are no updates (or, no business-initiated updates), data consistency is no longer sacrificed by data duplication.

There are a number of different solutions buzzing around right now that try to ressurect virtual data warehousing under the unbrella of EII (Enterprise Information Integration) solutions, but even most of the EII zealots will admit that this only supplements but does not replace a traditional physical, integrated data store for the core of data warehouse.

Now, transaction process in a whole different beast. And there is nothing, absoultely nothings, about current SQL RDBMS's that prevents you from maintaining you data at 100% consistency, if that's what you're aiming for. If you checks and foreign key constraints won't enforce your consistency, then triggers can.

My experience has been that most production transaction systems, even reliable and robust ones, share the responsibility of data consistency between the application and the db, often for performance reasons. But, if you wanted to do it all in the DB, you certainly could.; Posted by: jcg_z Posted on: 10/20/05 You are currently: a Guest | Members login | Terms of Use