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.
> If you name the PK clearly and distinctively you can keep the name
But why would you want to in the first place? 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.
> > 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?
> > But I'm also a huge believer in the principle that Primary Keys should
> > always be meaningless.
> But they're not meaningless! Sure, sometimes -- even often -- its
> suitable to have a pure number from a sequence. I've had systems in the
> past where part number was coded. There could be a sequence as -part- of
> the pn but it had other fields which meant something. In particular, this
> was a manufacturer of cable trays. Parts could be the tray, a bolt, a
> strap or other kinds of hardware. Trays had a number, bolts a number and
> so on. Then you have the particular kind of tray or bolt (perhaps coated
> with something, and you would then have particular kinds of coating with
> their own particular meaning including uncoated as a kind of coating).
> Length of part could be directly represented in the number as well.
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.
Tony
_______________________________________________
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