[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: XML database enviroment using PostgreSQL

• To: Doug Rudder <drudder@d...>
• Subject: RE: XML database enviroment using PostgreSQL
• From: Rick Marshall <rjm@z...>
• Date: 19 Aug 2003 08:53:21 +1000
• Cc: "'Elliotte Rusty Harold'" <elharo@m...>, Chiusano Joseph <chiusano_joseph@b...>, xml-dev@l...
• In-reply-to: <7FEEE73A06F3D411A99D00508BD6341002713816@FACEXCH1>
• Organization: Zenucom Pty Limited
• References: <7FEEE73A06F3D411A99D00508BD6341002713816@FACEXCH1>
• Reply-to: rjm@z...

hi all,

i'm still muddling around with ideas on how to extend our database
system to use xml in some sort of native mode

so here's my take on the problems about mixing the data/narrative
aspects of xml

1. for simple storage and then retrieval i don't think there's much in
it.

2. having said that, there is a performance hit for data storage when
records have to be reconstructed from bits before they can be used. if
you don't need to reconstruct a flat record (as we don't) then it
probably doesn't matter

3. the biggest problem to my mind is data stability - narrative material
and archival data <emphasis>tends</emphasis> to be stable. often never
changing from it's original form.

4. data, particularly operational data, tends to be unstable. database
systems have a life because they can manage the dynamics of data
efficiently. in fact this is one of the driving forces behind database
evolution. how to find and update records.

5. you could characterise this by saying a narrative xml database could
be useful if it could simply store and retrieve documents.

6. noone would dare go to market with a database system that didn't
include some sort of data update facility.

7. which brings us to the storage problem. database updates are quick
and easy when the record structure is regular - each record is the same
shape. the existing space will always hold an update.

8. xml "records" are by definition not regular so updates and free space
management are significant issues.

9. this is not to say that applications in both areas don't have some
overlaps - databases to store experiment results eg tend to be stable
while xml documents as working drafts tend to be unstable - at least for
a while.

10. so for my part i have now have two characteristics that help
determine the difference between the two - regularity of record
structure, and dynamics or stability.

just some ideas....

rick

On Tue, 2003-08-19 at 00:36, Doug Rudder wrote:
> <qoute>
> When I say record-like, I'm thinking database like records, not 
> storage records. Ah, the wonders of English. Perhaps field-like or 
> table-like might be better?
> </qoute> 
> 
> Fielded data vs. full publishing content worked well in
> presentations/discussions (in those specific venues).  Depends on the
> audience.  Sometimes it's beneficial to have been an English major;
> explaining these concepts to technical staff, in-house pharmacists (drug
> information group), and editors/tech writers certainly exercised one's
> ability to communicate with varied audiences! :-)
> 
> ____________________________________
> Douglas Rudder     drudder@d...
> 
> -----------------------------------------------------------------
> 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>

• References:
  • RE: XML database enviroment using PostgreSQL
    • From: Doug Rudder <drudder@d...>

• Prev by Date: Re: RelaxNG question
• Next by Date: Re: "Types" of XML (Was Re: XML databaseenviroment using PostgreSQL)
• Previous by thread: RE: XML database enviroment using PostgreSQL
• Next by thread: RE: Symbol Grounding and Running Code: Is XML Really E xtensible?
• Index(es):
  • Date
  • Thread