RE: Primary and Foreign Keys

["Bullard, Claude L (Len)" <clbullar@ingr.com>]

Or link.  Depends on the processing. In one document, you can handle
compounds 
using IDREFS but no, you can't assume uniqueness so blarg.   Nesting makes
sense 
for child tables.

My guess is for the particular system I am looking at though, it will need 
to be broken into multiple documents.   200+ tables, over 5200 fields, 
different configurations, the works.   Then there are issues of whether 
one is designing the schema for one system or as a potential standard 
data description for different systems.  One can't assume the design 
is for the internet per se.  Many field systems run in an occasionally 
connected mode.   In some respects, file management works ok because 
that is simple to encrypt and ftp works as long as the port is available. 
You can't assume the data will be transferred and destroyed.  Some kinds 
of systems demand copies of transferred files for traceability.

Len 
http://www.mp3.com/LenBullard

Ekam sat.h, Vipraah bahudhaa vadanti.
Daamyata. Datta. Dayadhvam.h


-----Original Message-----
From: Ronald Bourret [mailto:rpbourret@rpbourret.com]
Sent: Wednesday, July 25, 2001 1:18 PM
To: xml-dev
Subject: Re: Primary and Foreign Keys


"Thomas B. Passin" wrote:
> 
> [Ronald Bourret]
> 
> >
> > 6) Leave the key value out of the XML document. This requires that
> > nesting is used to indicate key relationships and makes sense when: (a)
> > key values are generated by the database, and (b) the data is being
> > transferred to a different database. Such values not guaranteed to be
> > unique in the second database.
> >
> 
> I almost included this thought in my post, but didn't because it occurred
to
> me that even if you nested a child entity within a parent, you might still
> need to refer to it from somewhere else rather than duplicate its data. 

True. The decision of whether to duplicate the data probably depends on
how you are processing the document. With SAX, it's easier to process
duplicate data, since it reduces caching. It also depends on what role
the document plays. If it's a simple data transfer -- the document will
be created once, read, and destroyed -- duplicate data probably isn't
that dangerous. If the document will be around for a while -- especially
if it can be updated -- duplicate data raises the possibility of
introducing inconsistencies.

> So
> it seemed that eliminating the ID and nesting could be orthogonal.  A
> case-by-case decision, methinks.

Semi-orthogonal. If you eliminate the ID, you have to nest in order to
show the relationship (unless I'm missing something). If you nest, you
don't have to eliminate the ID.