I've been away and busy and never had a chance to respond to this. I decided to continue the response as a sqlite-users thread (as opposed to just responding directly to andrew) in case others wish to listen-in or respond.
i am developing a brand new application (manager) that is 'constrained' only in that it must manage remote legacy appliances the speak xmlrpc. also, the new manager will be a web-based app running in tomcat.
since xml is all over the place (legacy product API, tomcat cfg, product cfg, roles and responsibility cfg, etc...), it seemed conceivable to me that it could be helpful (read: simpler, more maintainable) to hide and persistent/db semantics from the application and let it only view data as xml and/or internal objcts (beans/servlets/etc...).
since the new product development is still in the 'conception' stage - even the object hierarchy/relationships are not fully defined - at this moment, i have enormous flexibility wrt architecture.
I am also trying to quantify/understand the trades-offs between object .vs relational db mgmt. (the mgmt app will not be an embedded application, but will run on, say, a linux server. the appliances it manages are embedded apps and will in fact use SQLite (in later releases) as will new embedded product dev't.)
I am not all that db savvy wrt these issues, so i will listen to any offered advise, esp in the way of guidelines, that will help me make the right architectural decision.
Tia,
- rich
Andrew Piskorski wrote:
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.
-- rich coco [EMAIL PROTECTED] 781.736.1200 x165 Starbak Inc. 29 Sawyer Rd. Waltham, MA 02453
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
