OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   Re: [xml-dev] XML and the Relational Model (was Re: [xml-dev]A standard

[ Lists Home | Date Index | Thread Index ]

<Quote>
So. I say again. Show me. Prove it. Publish proofs, academically, that
-  an XML only solution (Heirarchical Model or HM) is better than an
dbms 
(RM) solution for the liftetime of the application
-  a primarily XML (HM) approach is superior over the lifetime of the 
application to a dbms approach (RM).
</Quote>

There are also times when a mix of the two is appropriate. For example,
in a scenario in which XML-formatted data is being exchanged between
systems via Web services, it can be very valuable to persist an XML
transaction in a native XML database for a period of time in the event
that a transaction rollback is necessary, or at a reliable messaging
layer in which a transaction needs to be resent because an expected
acknowledgement was not received by the sender on the first
transmission.

And of course if one or both of the applications stores data in a
relational database, the RDBMS aspect would come into play.

Kind Regards,
Joe Chiusano
Booz | Allen | Hamilton

pop3 wrote:
> 
> Well, now, then lets get specific. What index on what table in what SQL
> dbms, version and text please....
> 
> Not sure what building XML by hand has to do with what I thought I was
> discussing here, maybe I missed something or misread something...
> 
> You have good points, and what you say is not something I question, but I
> do question whether scaling what you say up to terabyte system levels is
> doable, reliable, maintainable and a best practice in TQM, PE, CMM or
> ISO9000 context.
> 
> My experience is that adding an index adds perpetual maintenance
> requirements, as well as increasing the daily overhead processing time and
> original complexity of the product in my opinion, in all cases, generally
> speaking (pun intended). The trade off of benefit  (speed gain result)
> versus initial and long term costing factors has to be carefully (dare I
> say Scientifically) evaluated. Faster is not always better, state of the
> art is not always better or cheaper, both of these are not always lower
> cost, and even initial lower cost results are not always proof of success
> of the project.
> 
> Call me silly, call me a neanderthal if you like, but I just don't want to
> see projects with budgets in the hundreds of millions, or billions of
> dollars fail.  It has happened before, in the past four or five years, to
> very well known companies like IBM, for precisely the reasons I have cited
> above and elsewhere.
> 
> So. I say again. Show me. Prove it. Publish proofs, academically, that
> -  an XML only solution (Heirarchical Model or HM) is better than an dbms
> (RM) solution for the liftetime of the application
> -  a primarily XML (HM) approach is superior over the lifetime of the
> application to a dbms approach (RM).
> -  business cases that show the best practice is primarily, or solely, and
> XML practice.
> 
> Open call. Any cases, any process, anything at all. Please. Pretty Please.
> Note that I did not even limit this to DATA only applications....
> 
> My belief is that when folks do the math, actually work through the proofs,
> they will find their own errors, and thereby become self-correcting, saving
> me alot of time and typing, and everyone else in business alot of money.
> 
> Also, I look forward to learning a thing or two... if the work is done
> properly and widely published / reviewed.
> 
> One might be able to build a mud hut without doing structural engineering,
> or load calculations... but scaling the building component of one story mud
> huts, that being mud and straw bricks, up to a skyscraper scale requires
> building in monolithic (pyramidal) structures in very dry climates, or
> facing failure.
> 
> My rule (Quality Standard, or Definition of Best Practice) is that IF it
> cannot be shown to work, and to be supportable over time within an
> acceptable cost factor, on a test bench then it should not be undertaken as
> part of a huge production project. Ergo the need for proofs, for
> development guidelines, for clearly stated and widely published development
> standards, acceptable practices and unacceptable practices (W3C perhaps?),
> and for understanding the limits of the technology being employed.
> 
> What I hear people saying is that XML has no limits, which I find to be a
> preposterous statement. :) "... but the document can be _-anything__ you
> want it to be.... you can do any system in XML better than in anything
> else...."  etc. etc. yeah yeah yeah... heard it all before, when people
> used the word "spreadsheet" instead of the word "XML".
> 
> Just my opinion.
> 
> Thanks!
> 
> Larry Bradshaw
> 
> At 03:58 PM 8/25/2003 -0400, Jonathan Robie wrote:
> >At 02:30 PM 8/25/2003, pop3 wrote:
> >>I agree that mappings among models are useful.
> >>
> >>But I wish to note that the farther one gets away from the hardware the
> >>less robust, slower and harder to optimize the resulting system becomes.
> >>Specifically, if the application design for a terabyte system works out
> >>to be a mapping between an rdbms and an XML tool like TeraText, and then
> >>a separate, different mapping between the XML tool set back to a rdbms,
> >>then my point is that the resulting system will have more failure points,
> >>be harder to tune, and generally less robust than a "native" system.
> >
> >You seem to like broad generalizations. Adding layers can improve
> >performance - for instance, adding a cache or indexed access involves
> >adding another layer of software, and either one does make the system more
> >complex, but it also improves performance. Similarly, adding a query
> >optimizer makes the system significantly more complex, but it does not
> >really make it harder to use or hurt performance.
> >
> >>Mappings, if you ask me, are bridges... like bridges they are an
> >>infrastructure that is high maintenance and which require above normal
> >>attention to support, and are subject to replacement periodically at high
> >>costs.
> >
> >For our SQL/XML product, we have found that using the SQL/XML extensions
> >generally results in faster programs than building the XML "by hand" using
> >the DOM. The reason for this has a lot to do with the structure of the
> >mappings between XML and relational, and the number of database calls
> >required by the approaches people generally use when solving this problem.
> >Here's a paper that discusses this at a useful level of depth:
> >
> >         SQL/XML in JDBC Applications
> >
> >http://www.datadirect-technologies.com/products/connectsqlxml/docs/sqlxml_whitep.pdf
> >
> >I think this also applies to XQuery. It's pretty easy to imagine what it
> >would look like to add a section on XQuery to the above paper.
> >
> >Jonathan
> >
> >-----------------------------------------------------------------
> >The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
> >initiative of OASIS <http://www.oasis-open.org>
> >
> >The list archives are at http://lists.xml.org/archives/xml-dev/
> >
> >To subscribe or unsubscribe from this list use the subscription
> >manager: <http://lists.xml.org/ob/adm.pl>
> >
> >
> 
> -----------------------------------------------------------------
> The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
> initiative of OASIS <http://www.oasis-open.org>
> 
> The list archives are at http://lists.xml.org/archives/xml-dev/
> 
> To subscribe or unsubscribe from this list use the subscription
> manager: <http://lists.xml.org/ob/adm.pl>
begin:vcard 
n:Chiusano;Joseph
tel;work:(703) 902-6923
x-mozilla-html:FALSE
url:www.bah.com
org:Booz | Allen | Hamilton;IT Digital Strategies Team
adr:;;8283 Greensboro Drive;McLean;VA;22012;
version:2.1
email;internet:chiusano_joseph@bah.com
title:Senior Consultant
fn:Joseph M. Chiusano
end:vcard




 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS