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: Magick, Brian [mailto:Brian.Magick@compaq.com]
> Sent: 17 October 2001 20:41
> To: Ranjeet Sonone; xml-dev@lists.xml.org
> Subject: RE: [xml-dev] XML Database Decision Tree?
>
> Agreed.....the intent of my original post was NOT to get information on
> any XML databases.....this is not my concern, I just want to know in a
> general sense when to XML and when not to in regards to creating
> database applications or storing data in databases.
[...]

I think that this would be a really useful exercise. Have you considered
culling relevant information from Ron Bourrets XML and Databases
review [1]? Might this give you the information you need?

Following the track of previous activities, it'd be useful if someone
summarised
this discussion (which might include off-list suggestions, with permission)
and
reported it back to the rest of us.

For my own part (in a largely document-centric world) I've found that the
'relational plus XML facilities'
offers some good flexibility. Particularly where there's a mixture of data
types
(e.g. documents, and transaction records).

It's a fairly common XML design pattern to have a head-body structure
to your schema [2]. e.g. metadata (author, title, etc) and content (paras,
markup, etc). Processing the XML to pull out the information in the head
into standard relational tables, whilst leaving the content as a BLOB or
referenced file meets most requirements.

Generally speaking it's the head information that needs indexing, will be
most queried on, etc. It's usually least likely to include mixed content
which
makes the decomposition easier.

The additional XML features of the database can then be utilised in the
circumstances where you need to do something with the body content
(e.g. picking out/updating individual elements). Although obviously one
could
roll this up into the application layer.

Cheers,

L.

[1]. http://www.rpbourret.com/xml/XMLAndDatabases.htm
[2]. http://www.xmlpatterns.com/HeadBodyMain.shtml

p.s. I should have labelled my posting 'Proposal for XML posting
guidelines'. As that's what it is.

--
Leigh Dodds, Research Group, Ingenta | "Pluralitas non est ponenda
http://weblogs.userland.com/eclectic |    sine necessitate"
http://www.xml.com/pub/xmldeviant    |     -- William of Ockham