[
Lists Home |
Date Index |
Thread Index
]
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>
>
>
|
