[
Lists Home |
Date Index |
Thread Index
]
- To: Michael Kay <mike@saxonica.com>
- Subject: Re: [xml-dev] Indexing solution for native XML database
- From: Peter Hunsberger <peter.hunsberger@gmail.com>
- Date: Thu, 1 Dec 2005 08:40:44 -0600
- Cc: xml-dev@lists.xml.org
- Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=FUkGwzATOS26ke7zU03Ajq35AezIXuE3VkPr68qQo41BygHKtuURxXH9w1klRBtt3dHPzbmVZ3qVNo/XM5K9nm/46JH/Iz/rwKlTM1ieGzcZ/3Il3Vj7+O9zCoEDXAcGNJP0Adb7OnvFCdHYmwOzuWX6JlLddqKZ7yJNJhnwTis=
- In-reply-to: <20051130220004.B23C02F51D0@mailhost3.dircon.co.uk>
- References: <cc159a4a0511301331r7d03b0a7m6f22661233c63491@mail.gmail.com> <20051130220004.B23C02F51D0@mailhost3.dircon.co.uk>
On 11/30/05, Michael Kay <mike@saxonica.com> wrote:
> > 2) there's often a need to mix tree models with standard relational
> > data. In our case 90% of the data fits a relational model very well.
> > The 10% that doesn't is critical and it can't easily be separated out
> > into something else.
> >
> > For the latter case, what kind of approach do you recommend?
>
> Sure, you often have to make compromises, using the optimal technology for
> each part of a problem is probably not optimal overall.
>
> I started out by saying that if I was building an XML database then I
> wouldn't by choice build it on top of a SQL database, and I stick with that.
I've always agreed that if you've got to set out to design a database
to store any random piece of XML that comes along you wouldn't likely
want to start to with an RDB. What I didn't understand was your
object to Celko's adjacency list approach.
Reading between the lines, it seems that you feel That Celko's
writings encourage a belief that it is good enough approach that
nothing else is needed? In a way, for people doing data (as opposed
to (cough) document (cough)) storage I feel it is sufficient. The
restriction being that you're working in a single application domain,
and not, for example, trying to store random SOAP transactions or
such. In such cases the bulk of the data is repetitious and the
hierarchies are small. Even with things like parts inventories where
the hierarchies may not be fixed they are usually not updated on a
regular basis: you build the part description once and you can then
retrieve it with a single flat query.
I don't know where the inflection point is that causes one to start to
look at alternative models. Certainly even medium requirements for
update can make such models fall apart. However, for the real world I
suspect that they are actually very useful. What would make them even
more attractive is a couple of standardized schema's and prebuilt data
management engines that embodied best practices as nicely as Saxon
does for the XML/XSLT world... ;-)
--
Peter Hunsberger
|
