I don't know a lot about fully normalized relational database but I do know you can read the the schema of a database. (Again - just thinking out loud) They have Master Data Management (MDM) tools that collect, aggregate, match, consolidates, persists and distributes data to ensure consistency and control of this information.
By using this kind of tool, theoretically, you could re-build your schema in an MV format that would take advantage of MV technology. To Ross's point, the technology might not be there for real-time processing across databases, however, you could get near-time. And outside of transactional processing, near-time meets the needs of most projects. I just see a lot of people looking to migrate data off of MV, I think by creating an "easy" migration path to (and from) an MV environment, you would draw more attention. Not to get to far into this discussion (at this time) I respectfully disagree with those who have said that your data needs to be application specific. This thought puts the emphasis on the application and not on the data. And it's all about the data! Applications are easy to build and they SHOULD be much more dynamic then they currently are and that is because business is dynamic. 'We act as though comfort and luxury were the chief requirements of life, when all that we need to make us happy is something to be enthusiastic about.' ----- Original Message ---- From: Wols Lists <antli...@youngman.org.uk> To: u2-users@listserver.u2ug.org Sent: Wed, December 22, 2010 6:01:09 PM Subject: Re: [U2] Migration On 22/12/10 19:49, Shawn Hayes wrote: > Why would it need to be application specific? I was just thinking that > architecturally (sometimes) there are advantages to using a non first normal > form databases. If you can read the schema of a fully relational database, > couldn't you "easily" enough re-create the files embedding child elements > into > MV tables? NO. (Sadly) I've read the other replies saying it's "application specific". And it is. Ask yourself how you're going to *program* your migration tool to know which tables should be merged into an MV file. It can't be done. And the reason is inherent in relational theory. In theory, an attribute can exist on its own. In reality, an attribute is like an adjective, with nothing to describe it doesn't exist. How is your migration tool going to work out which adjectives describe which noun, and hence which attributes belong in the same file, and which ones don't? You can guess, but chances are you're going to make *several* mistakes, which could seriously damage all the advantages MV brings. Cheers, Wol _______________________________________________ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users _______________________________________________ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
