I don't know of a good reference, but I've been told (and agree with)
that one should never use "natural" keys. Even natural keys that are
guaranteed to be unique and never change, aren't 100%.
For example, assume you are working on a banking application and you
decide to use a social security number as a natural primary key (instead
of an arbitrarily generated one). When someone sets up an account, they
could incorrectly enter the social security number. This error is
discovered by the customer after they receive their end-of-year tax
information and they call the bank to report it. If you are using the
social security number as a primary key (because it never changes,
right?), you'd have to update the key that never changes and track down
and update everything that references it. Most likely this will be a
support request, because that feature won't be designed into the
application (and if it's designed into the application, it requires even
more development work). It's much easier to just change the social
security number. Then you can re-print their forms and re-submit to the
tax administration.
Hope that makes sense!
/dev/mrg
-----Original Message-----
From: Steve Wells [mailto:stwell..wnmail.net]
Sent: Monday, February 02, 2004 2:13 AM
To: Andrus Adamchik; cayenne-use..bjectstyle.org
Subject: Re: Help: Hollow class
Hey Andrus,
Excellent that works. I guess I was still trying to link on the old
natural-key columns instead of using generated ones...still getting my
head around this concept. I would have actually thought I could "join"
on any arbitrary columns?
Is there a good reference somewhere explaining the benefits of generated
vs meaningful/natural keys?
Thanks for the speedy and very helpful response.
Steve
On Mon, 2 Feb 2004 01:27:46 -0500, "Andrus Adamchik"
<andru..bjectstyle.org> said:
> Hi Steve,
>
> Just from looking at your mapping, what I think confuses Cayenne (and
> confuses me as well), is the fact that the relationship "whitelist ->
> org" doesn't point to the primary key (id), but rather points to
> another column (shortName). Any reason why you don't want to create
> "whitelist.orgId" column that points to org.id?
>
> Thanks
> Andrus
>
> On Feb 2, 2004, at 12:47 AM, Steve Wells wrote:
>
> > My datamodel is basically a 1 to many:
> > Whitelist (a list of valid email suffixs for an Org) - The many side
> > <db-entity name="whitelist" catalog="lgo">
> > <db-attribute name="emailSuffix" type="VARCHAR"
isMandatory="true"
> > length="120"/>
> > <db-attribute name="id" type="INTEGER"
isPrimaryKey="true"
> > isMandatory="true" length="11"/>
> > <db-attribute name="orgName" type="VARCHAR"
isMandatory="true"
> > length="20"/>
> > </db-entity>
> >
> > Org - An organisation - the one side
> > <db-entity name="org" catalog="lgo">
> > <db-attribute name="id" type="INTEGER"
isPrimaryKey="true"
> > isMandatory="true" length="11"/>
> > <db-attribute name="shortName" type="VARCHAR"
isMandatory="true"
> > length="20"/>
> > </db-entity>
> >
> > The relationships:
> > <db-relationship name="toOrg" source="whitelist" target="org"
> > toDependentPK="false" toMany="false">
> > <db-attribute-pair source="orgName" target="shortName"/>
> > </db-relationship>
> > <db-relationship name="toWhitelist" source="org"
target="whitelist"
> > toDependentPK="false" toMany="true">
> > <db-attribute-pair source="shortName" target="orgName"/>
> > </db-relationship>
> > <obj-relationship name="toOrg" source="Whitelist" target="Org"
> > toMany="false">
> > <db-relationship-ref source="whitelist" target="org"
name="toOrg"/>
> > </obj-relationship>
> > <obj-relationship name="toWhitelist" source="Org"
target="Whitelist"
> > toMany="true">
> > <db-relationship-ref source="org" target="whitelist"
> > name="toWhitelist"/>
> > </obj-relationship>
>
-- http://www.fastmail.fm - Or how I learned to stop worrying and love email again
This archive was generated by hypermail 2.0.0 : Mon Feb 02 2004 - 11:08:02 EST