On Wed, 2 Feb 2005, Tony Bowden wrote:
> On Tue, Feb 01, 2005 at 08:25:23PM -0500, Dana Hudes wrote:
> > > > From a documentation perspective, if I have a PK that I then use
> > > > as a FK somewhere, gosh but it makes life so much clearer to use
> > > > the same name.
> > > Why? I don't buy this one.
The name for the value remains consistent. The question you have to ask
yourself is this a new thing, i.e. have you done or will you do some
transformation, or is it the same thing? If its the same thing, why are
you now making me wonder where this new thing came from?
> > If you name the PK clearly and distinctively you can keep the name >
> But why would you want to in the first place?
Clarity. Hmm. Have you read Frederick Brooks _The Mythical Man Month_?
I don't have a copy (I had read a library copy back in grad school).
I feel this was addressed in an early essay in Yourdon's collection
_Writings of the Revolution_ but I can't find my copy at the moment.
I -have- got my copy of
Blaha, Michael and William Premerlani _Object-Oriented Modeling and Design
for Database Applications_
and they reinforce some of what I've said:
from pp24-25 section 2.2.6 Qualified Associations:
"A qualified association is an association in which th eobjects in a
"many" role are partially or fully disambiguated by an attribute called
the qualifier."
> This is a technical
> answer. I'm looking for a philosophical one. You say it makes things
> clearer. I say it's clearer to just use the table name.
Take a bank account. You CAN just call its key "accountNumber".
Would it not be clearer to say which bank ? Or which institution?
Consider some organization like Citigroup. They've got bank qua
bank,Citibank, they've got bank qua investment house (Smith Barney) and
they've got an insurance company (Travelers). They've also got Citicards
(Diners Club , VISA/MC, and then they do card processing for private
labels like AT&T Universal card).
Each of these organizations gets back-office service from CGTI, the
Citigroup Technology Infrastructure organization. A data modeler, for
example, will likely bounce around amongst projects for all of these
organizations (I certainly did as a LAN engineer!). When you look at a
piece of code or a UML diagram, what do you want to see?
accountnumber
or
CitiCheckingAccountNumber
?
>
> > > I find it much clearer to make FKs the name of the table to which they
> > > refer.
> > If the PK name includes the table name
>
> Why bother?
disambiguation
> This is bad bad bad bad bad.
>
> PK's should *always* be meaningless.
>
> Adding data in about things like part numbers, tray numbers etc leads to
> a world of pain when supposedly invariable data changes, as, invariably,
> happens.
If you mean that its one column you may well have a point however
if you have a MCPK composed of the column for part-type, coating and so on
then where's the problem? If you change the coating you have a new part!
Oh sure maybe performance is better on a SERIAL rather than a MCPK of 5 or
6 columns -- for insertion of a new part, which is done relatively rarely.
If you are assembling a PO, however, you already have all the columns
loaded.
Furthermore if you are allowed to just use a pure SERIAL for the PK for
part, then parts can change without changing the part #.
Consider that I have all sorts of object containers lying around using
this! Purchase Order, Bill of Lading, Invoice etc. .
If you're allowed to go changing the coating you change the meaning of
what was sold to someone!
_______________________________________________
maypole mailing list
maypole at lists.netthink.co.uk
http://lists.netthink.co.uk/listinfo/maypole
This archive was generated by hypermail 2.1.3 : Thu Feb 24 2005 - 22:25:58 GMT