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

RE: Primary and Foreign Keys

  • From: "Bullard, Claude L (Len)" <clbullar@i...>
  • To: Ronald Bourret <rpbourret@r...>, xml-dev <xml-dev@l...>
  • Date: Wed, 25 Jul 2001 13:38:03 -0500

duplicate foreign keys
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@r...]
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.

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.