Re: Separate PK in Jxn Tbl?

David Cressey wrote:

> <CDMAPoster_at_fortunejames.com> wrote in message
> news:a12c7757-aea7-4d11-bf7c-3bd4b7feb442_at_n20g2000hsh.googlegroups.com...
> On Jan 25, 9:12 am, Jamie Collins <jamiecoll..._at_xsmail.com> wrote:
> (quote)
> What part of simpler don't you understand :-). Only one expression in
> the ON is simpler. Needing less indexes is simpler. Not having to
> look for your multi-key fields is easier, although your point that
> Relationships can handle that is valid. If the AutoNumber key has a
> one-to-one relationship with the multi-key fields then it's fine to
> use it. There's no down side that I can see. I also like to rely on
> coding to detect inconsistent data rather than on error trapping, so I
> have to check the multi-key values anyway before adding a new record.
> I think that your idea about enforcing constraints at both the table
> level and in code is an excellent idea. The OP wanted to know what
> people did and why. I still don't see any reason put forward for me
> to change to a multi-field key. Are totals queries easier when multi-
> field keys are used? BTW, "reduced the amount of denormalization"
> works just as well. Real databases experience denormalizing
> influences.
>
> (end quote)
>
> Simplicity is in the eye of the beholder.

I tend to disagree. I suspect one can quantify simplicity and complexity.

> I think it's simpler to rely on constraints enforced by the DBMS to prevent
> duplicate entries
> than it is to write code to accomplish the same thing.

Using the dbms uses fewer tools, fewer concepts, fewer computational models, fewer structures, fewer machines. I suggest the observed simplicity is more than a matter of perspective or opinion.

[further demonstrations of simplicity snipped] Received on Sat Jan 26 2008 - 18:05:12 CET