On Thu, Apr 15, 2004 at 02:37:13PM -0400, rich coco wrote: > >>the goal would be to abstract out of the application the entire > >>DB schema and allow the application to work exclusively with XML - > >>and the generated methods - wrt not only data representation and > >>transport but data storage and retrieval too. (ie, the application need > > > >And WHY would you want to do that exactly? To me it sounds like an > >excellent strategy to recommend to a competitor.
> please tell me more...as in why it's a bad idea. It's not that I know it to be a bad idea - I don't. Perhaps it's actually a very nice idea. But without knowing more, it sounds like a good way to make things a lot more complicated than they need to be for no gain. If you're using a RDBMS, why not just use the RDBMS? Generating some sort of limited XML format for sending over the wire to some remote application, sure I can see the value of that. But converting your entire relational schema to XML for internal use in your own program? Why? What can that possibly buy you over just using the relational schema directly? I mean, heck, the relational model was invented for a reason, why would you want to transform it to a hierarchal XML model and have your program manipulate that? And if (for some reason I can't fathom) what you really want is some sort of tree-structured XML schema, then why not use an native object or XML database or persistent storage API intended for that, rather than repeatedly converting between the RDBMS and XML? If you tell me you're sure there is some good reason I may be prepared to believe you, but offhand I can't think of one myself. -- Andrew Piskorski <[EMAIL PROTECTED]> http://www.piskorski.com/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
