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


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [xml-dev] XML Database Decision Tree?

----- Original Message ----- 
From: "Eric Lemond" <elemond@neocore.com>

> I'm struggling with the car analogy a bit.  Help me if I'm
> misunderstanding.  

So am I. The origianl analogy was not mine.
I was talking about cars. ;-) For cars - it's obvious 
that one can store more cars if splitting them into 
parts. With databases it is not so obvious, of course.

>>Paul T
>>If the process of dismantling / re-assembling is really fast and 
>>robust ( no parts would get lost ), the advantage is that you can 
>>park 10-1000 times more cars in the same space.  And perhaps 
>>have more trees in downtown as a side effect.

> XML DBMS's (at least some of them) have a smaller storage footprint than
> an indexed RDBMS.  Sometimes it's even smaller than the size of the
> original data set.  

Link? And if so - the speed of search/update may be horrible.
Last time I checked, all native XML databases were 
not as scalable as good old RDBMS-es.

I'm ready to change my mind, if some vendor 
will show me a *signle* *reasonable* benchmark,
instead of showing W3C buzzwords ( Xpath,  XSLT 
e t.c. )

I'd *love* to see a *single* benchmark, like :

1. Here is the testcase.
2. We've done it with 'native XML product X'
3. We have a following benchmarks ... (on 
the hardware 'Y') 
4. Then we've mapped the same solution to RDBMS
( 'Z' )
5. Here are the benchmarks ( on the same hardware 'Y' )

And I'd love to do that benchmarking on, say, 
MS Windows and Linux platforms, not on some 
'cool CPU's. 

And some time ago I've said that I'm ready to 
help preparing these  benchmarks. For free.

I can say the same thing again. ;-) I don't see 
many changes in the world of native databases ;-)

> Therefore, wouldn't the analogy be dismantling the
> car and putting all the individual parts in storage containers equal in
> size to that necessary for the largest part.  Even though ball bearings
> don't need the same amount of space as the car frame, they get that much
> space.  In the end, we can store ~1/10 the original number of cars.  I
> agree that sometimes it's best to dismantle/reassemble, but I don't
> think the storage part fits.

Well, I was estuimating 10-1000 for the situation, when the car is 
from future and it is composed from greater number of smaller  
parts. The real problem of constant resemblings is that it eats 
power. Like servers do anyway.