Many-to-many question

Question

Just asking for some help with some search terms, as I know that this topic has been argued out somewhere. I just haven't been able to find it:
If I'm setting up a cross-reference/junction table in order to fulfill a many-to-many requirement, should I create a technical key as a primary key with a unique index on the combined foreign keys? Or should I make the combination of the foreign keys the primary key?
Our newest standards force a technical key on all tables, and one of the Developers is asking why that's necessary on a cross-reference table. I've searched on "cross reference table primary key", "junction table primary key". Most answers suggesting a technical key are due to database performance issues that can be solved with it (not suggested for that reason for Oracle that I've found yet).
--=Chuck

Answer 1

>
If I'm setting up a cross-reference/junction table in order to fulfill a many-to-many requirement, should I create a technical key as a primary key with a unique index on the combined foreign keys? Or should I make the combination of the foreign keys the primary key?
>
Assuming that each of your foreign keys is a surrogate key and not an actual data value, I have to agree with Dan on this one.
The two primary attributes that a key value should have are: 1) it should be unique and 2) it should have no inherent meaning.
By 'no inherent meaning' I mean it should NOT be a data value or have any meaning whatsoever attached to its value. If the value were to change it would have no impact at all on the actual data though naturally the value has to be changed the same everywhere it is used.
A classic example in the U.S. is social security number. It should NOT be used as a key even though it might be considered a 'natural' key.
The value is a data item that has meaning and is subject to change if for no other reason than typographical error. It is the problems involved in making changes to data items used as keys that surrogate keys are intended to prevent.
A surrogate key (even a sequence) has no inherent meaning. If a value of 2 is being used in a system and, unknown to you, someone changes the value to a 3 everywhere in your system that it is used you will never notice it.
I have seen no standard suggesting that multi-column surrogate keys are inappropriate. Your intersect table can use the combination of the foreign keys as the primary key and fulfill the contract of using surrogate keys.
Sven suggested this
>
For example you later discover that you want a detail table for your joined table. Then the detail table would need only one column as a foreign key constraint, instead of two (which can have major performance implications).
>
If if was desired to meet that future requirement by using one column you can easily do so by adding a new column specifically for that purpose without any impact whatsoeve on the existing system.
As for this possible architecture change
>
Or you add some third column to include into the uniqueness logic.
>
Well that requirement is a fundamental change to your existing one. The existing requirement is that the combination of the two foreign keys should be unique. It is not clear if Sven was suggesting that that requirement is no longer valid or if rather suggesting that there is no an ADDITIONAL requirement that those two values as well as a third should also be unique.
If you need to implement uniqueness for the two values you currently have as well as for those combined with a third value that would be better implemented by creating yet another INTERSECT table specifically for that purpose and leave the existing intersect table in place. That architecture approach expands the data model without disrupting the existing one.
The main design goal, in my opinion, should always be to produce a design which most easily meets current requirements without foreclosing the ability to meet unknown future requirements.