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 [email protected] http://listserver.u2ug.org/mailman/listinfo/u2-users
