Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.server -> Re: Development Trends in Web and Oracle

Re: Development Trends in Web and Oracle

From: Hexathioorthooxalate <ruler_at_removemetoemail.clara.co.uk>
Date: Sat, 12 Mar 2005 14:08:20 -0000
Message-ID: <1110636493.21027.0@ersa.uk.clara.net>


"Noons" <wizofoz2k_at_yahoo.com.au> wrote in message news:4232e7cb$0$5484$5a62ac22_at_per-qv1-newsreader-01.iinet.net.au...

> There is NO "so you are saying". What I said is PERFECTLY clear
> and understandable: an overhead of 73 times longer is NOT a
> The overhead? 36*2+1 longer to process a single byte

Ok the information being processed is more verbose, big deal! I still can't accept this is the sole basis you are using to not store XML in a database. Overhead of 36*2+1 longer ... Huh?? This calculation doesn't hold water. I elaborate.

73 times longer to "process" a single byte. Rubbish. 73 times inflated data for this specific example, possibly, but not 73 times longer to "process" the byte (see argument further down). You have calculated the information payload for 1 byte in Daniel Morgans example as 72+1=73 bytes. But for 100 bytes of data, this payload ratio is 72+100 bytes - far from 73 times inflation now and your argument is clearly less convincing. Further, and this whole argument is based on extremes, most XML tags are not this long <RIDICULOUSLYLONGTABSIGNIFYINGNOTHING> + closing tag.

But in terms of your overhead calculation for "process"ing (your word) the information, it also just is not right. To process a "byte", prior to the DMBS persisting the information, there is much more that needs to be done over and above just receiving the "byte". This is only a small part of the story. The "byte", or most often more, has to be checked for validity by the DBMS for the requested operation (to check this "byte" to ensure it satisfies relational constraints or bounds checking etc). In a relational or object relational database, this might be done with table or column constraints, stored procedures, and triggers etc. ***This has additional overhead***. Generally orders of magnitude more.

With XML data stored in the database, the information being inserted can be checked for bounds, its content etc significantly more comprehensively than using the traditional relational approach (eg. XML schema on an XMLTYPE table column). Arguably this is more efficient. ***This has overhead too.***

Calculation of the relative overheads for XML and purely relational data is really the issue and it cannot just be distilled down to the number of bytes of information. Given the data verbosity is clearly only part of the story, dismissing the storage of XML in a database on this basis is I believe a very week argument.

So I ask again, what is the real reason for not storing XML in a database then?
Hex

"Noons" <wizofoz2k_at_yahoo.com.au> wrote in message news:4232e7cb$0$5484$5a62ac22_at_per-qv1-newsreader-01.iinet.net.au...
> Hexathioorthooxalate apparently said,on my timestamp of 12/03/2005 11:46
> PM:
>
>>>The overhead? 36*2+1 longer to process a single byte.
>>>How fast a modern CPU works is completely irrelevant.
>>
>>
>> So you are saying the argument against storing XML in the database is a
>> cost overhead for a bit of verbosity? That can't be the basis of your
>> argument, surely?
>
> There is NO "so you are saying". What I said is PERFECTLY clear
> and understandable: an overhead of 73 times longer is NOT a
> "bit" of verbosity. It is bleeding obvious it is totally
> unnecessary and redundant.
>
> You want to give it your own spin, go right ahead.
> But it is YOUR spin.
>
>
> --
> Cheers
> Nuno Souto
> in sunny Sydney, Australia
> wizofoz2k_at_yahoo.com.au.nospam
Received on Sat Mar 12 2005 - 08:08:20 CST

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US