Separate PK in Jxn Tbl?

[Bob Badour]

(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]

 

[Sylvain Lafontaine]

Your argument about the use of a DRI WITH ON UPDATE CASCADE is an
interesting argument and one that come back often; however it's not a silver
buller. First of all, it's another level of complexity that you must add to
the design of your database; ie, you must make sure that they are all there
and no one is missing. Second, this DRI cannot be used with cyclic
relationship with SQL-Server but with Oracle, you can. (From your example,
I believe that you are working with Oracle). On SQL-Server, you must use
triggers to implement such a feature when there is a cyclic relationship.
Of course, when you are dealing with tens and hundreds of relationships,
this can quickly translate into a nightmare. There is also the qestion of
the diminution of performance and of general design: when you have to update
multiples records on multiple tables for what should be the change of a
single value in a single table make it hard to believe that this is a proper
normalized database design and this situation quickly worsen if you have to
take into account the correspondance with backups, reports and linked
databases; all systems for which there is no automatic DRI.

But why make it simpler when you can make it harder?

Finally, I don't understand your example at all. You are introducing us to
the NATURAL JOIN and USING statement that have been introduced by Oracle in
its 9i version (also in MySQL and Postgres, I believe) but I fail to see
what this has to do with the subject of this thread; the use of a separate
PK in a junction table and its highly related topic, ie. the use of natural
keys versus the use of surrogate keys. There is no relationship at all
between a NATURAL JOIN and a natural key and the Natural Join can be used as
easily with a surrogate key than with a natural key. The only thing that is
important with the Natural Join is the name of the key. (BTW, if you were
to ask me what I'm thinking about this little monstruosity, I would tell you
that this is a perfect example of a Pandora box.).

And finally, a for your request of asking me to convince you that I'm
properly understand the problem here of to etablish that I'm credible: I can
tell you that I have absolutely no intention of doing it and that I have
absolutely no interest at all about what you are thinking of me. The only
things that are of interest to me are the arguments that I'm seeing posted
here - whatever the people who might write them - but for someone who has
just make a confusion between a natural key and the NATURAL JOIN, asking for
such a thing make it looks very strange.

 

[James A. Fortune]

Yes, exactly.

One of the greatest benefits, and one of the fundamental
differences between how SQL treats data and how
(most) conventional programming languages treat data
is that in SQL we specify data by its value, instead of by
location. I often observe that superfluous keys in the field
are an attempt to make SQL data have an address, to
make it behave the way the programmer's mental model
(perhaps influenced by years of using pointers) does.


Marshall

Personally, I don't take the natural keys out either, so they can still
be used for the deletion. The thought of giving the SQL data an address
and following a programmer's mental model did not enter into my thinking
at all. I am not trying to give the data an order either. You've been
listening to Celko too much. Because of his overall manner, which I
find quite offensive, I don't even want to listen to him when he's right
. Is the AutoNumber primary key a denormalization of the schema?
Yes. Is it added for a reason? Yes again. I'm still waiting for a
cogent reason for me to go to using natural keys.

James A. Fortune
(e-mail address removed)

 

[James A. Fortune]

* Artificial keys allow you to enter the exact same statement of fact
twice. This would simply be nonsense.
* Artificial keys allows a tuple at t1 and a tuple at t2 to be
corresponded to each other, even if they don't have a _single_
attribute from the real world in common. This would also simply be
nonsense.

Access programmers use forms to interact with the data. If I follow
Jamie's advice and constrain the data at both the table level and in
code, then your points make more sense. Right now, they're just
arguments for me not to constrain the data at the table level because
the reasons you gave might make natural keys preferable in that
situation .

* Referencing an artificial key in a child table can complicates
queries - and not just with a longer restrict clause, but with a whole
extra join that may well have been unrequired if a natural key had
been used.

I don't agree with that point. The child table can contain the
AutoNumber primary key from the main table as a foreign key if desired.
I don't see how using the natural key fields requires less joins than
that. Maybe an example would help me understand what you mean.

So not one, but three cogent reasons of the top of my head. I wouldn't
say there are never cases when an artificial key is useful, but they
certainly shouldn't be hidden, and adding them blindly to every
relation is surely just a bit silly. Regards, J.

Did I imply that that's what I do?

James A. Fortune
(e-mail address removed)

 

[Bob Badour]

Personally, I don't take the natural keys out either, so they can still
be used for the deletion. The thought of giving the SQL data an address
and following a programmer's mental model did not enter into my thinking
at all. I am not trying to give the data an order either. You've been
listening to Celko too much. Because of his overall manner, which I
find quite offensive, I don't even want to listen to him when he's right
.

So, you object to Celko's style but consider him right?!? That's a new
one. ::rolls eyes::


Is the AutoNumber primary key a denormalization of the schema?

Yes.

You are an ignoramus. You don't even have a clue what normalization is.
The addition of an attribute to act as a simple, stable key does not
affect the normal form in any way shape or manner.


Is it added for a reason? Yes again. I'm still waiting for a

cogent reason for me to go to using natural keys.

It's the familiarity, stupid. The design criteria for keys are (and I
repeat): uniqueness, irreducibility, stability, simplicity and
familiarity (in no particular order.)

 

[Brian Selzer]

* Artificial keys allow you to enter the exact same statement of fact
twice. This would simply be nonsense.

Not exactly. Artificial key values are simply names assigned to individuals
in the Universe of Discourse. I would think that it should be possible to
have many different names for the same thing: considering the fact that
there are a great many different languages, there must therefore be a great
many words for each thing.

* Artificial keys allows a tuple at t1 and a tuple at t2 to be
corresponded to each other, even if they don't have a _single_
attribute from the real world in common. This would also simply be
nonsense.

I wouldn't call it nonsense. It is not necessary that every property that
an individual exemplifies be represented in the database--only those
properties that are relevant to the problem at hand need be included. In
that event, if a particular individual is assigned a name at t1, and then if
the values for all of the properties that are relevant to the problem at
hand at t1 are compared to those from the individual with the same name at
t2, it is possible for all of those properties to be different. That isn't
nonsense, it just is, given the inherent incompleteness of the information
in the database.

* Referencing an artificial key in a child table can complicates
queries - and not just with a longer restrict clause, but with a whole
extra join that may well have been unrequired if a natural key had
been used.

You left one out. In a table that has multiple natural keys, when an
artificial key is added, which key values are its values surrogates for?

 

[Brian Selzer]

Access programmers use forms to interact with the data. If I follow
Jamie's advice and constrain the data at both the table level and in code,
then your points make more sense. Right now, they're just arguments for
me not to constrain the data at the table level because the reasons you
gave might make natural keys preferable in that situation .

Well, that's just dumb. Checks in code can reduce database round-trips, and
therefore can improve performance, but are not and cannot be a substitute
for constraints on the tables. It is the constraints on the tables that
keeps garbage out of the database.

I don't agree with that point. The child table can contain the AutoNumber
primary key from the main table as a foreign key if desired. I don't see
how using the natural key fields requires less joins than that. Maybe an
example would help me understand what you mean.

An extra join may be needed if the natural key from the parent table is used
in a restrict clause. If all you have is the artificial key from the parent
table, then you have to join in order to access the natural key columns.
With natural keys, the natural key values from the parent table also appear
in the child table, so there isn't any need to join. Bottom line: joins of
artificial keys are typically faster than joins of natural keys due to the
size of the comparands, but with natural keys, fewer joins may be needed..

 

[Brian Selzer]

Well, that's just dumb. Checks in code can reduce database round-trips,
and
therefore can improve performance, but are not and cannot be a substitute
for constraints on the tables. It is the constraints on the tables that
keeps garbage out of the database.

If the users only access the tables through forms, conforming to best
practices in Access, how are they going to get garbage into the
tables? Now if you're trying to keep Jamie and his Excel SQL out of
your database, that's another story .
<<<<<

There can be several forms that access the same table, so you would have to
duplicate the code behind each form that accesses a table, or you can get
garbage into the database.

An extra join may be needed if the natural key from the parent table is
used
in a restrict clause. If all you have is the artificial key from the
parent
table, then you have to join in order to access the natural key columns.
With natural keys, the natural key values from the parent table also
appear
in the child table, so there isn't any need to join. Bottom line: joins of
artificial keys are typically faster than joins of natural keys due to the
size of the comparands, but with natural keys, fewer joins may be needed..

If you're planning on using a natural key column in the child table as
part of a join then doesn't it make sense to include that field in the
child table?

Still waiting...


A typical schema with artificial keys:

Customer {CustomerKey, CustomerNo, ...}
Key {CustomerKey}, Key {CustomerNo}

Item {ItemKey, ItemNo, ...}
Key {ItemKey}, Key {ItemNo}

CI {CustomerItemKey, CustomerKey, ItemKey, CustomerItemNo}
Key {CustomerItemKey}, Key {CustomerKey, ItemKey}
CI[ItemKey] IN Item[ItemKey]
CI[CustomerKey] IN Customer[CustomerKey]

SOLine {SOLineKey, SOKey, SOLineNo, CustomerItemKey, Quantity, Price}
Key {SOLineKey}, Key {SOKey, SOLineNo}
SOLine[CustomerItemKey] IN CI[CustomerItemKey]


A typical schema with natural keys

Customer {CustomerNo, ...}
Key {CustomerNo}

Item {ItemNo, ...}
Key {ItemNo}

CI {CustomerNo, ItemNo, CustomerItemNo}
KEY {CustomerNo, ItemNo}
CI[CustomerNo] IN Customer[CustomerNo]
CI[ItemNo] IN Item[ItemNo]

SOLine {SO#, SOLineNo, CustomerNo, ItemNo, Quantity, Price}
SOLine[CustomerNo, ItemNo] IN CI[CustomerNo, ItemNo]


Now write a query that returns how many of item '12345' were sold to
customer '4321'

It should be obvious that with the natural keys, no joins are
necessary--it's just a simple select from SOLine since all of the
information is actually /in/ SOLine; whereas, with the artifical keys,
several joins are required because in order to query by item number and
customer number, SOLine must be joined to CI which must then be joined to
Customer and Item.

 

[Bob Badour]

"Sylvain Lafontaine" <sylvain aei ca (fill the blanks, no spam please)>
wrote in message
[snip]

And finally, a for your request of asking me to convince you that I'm
properly understand the problem here of to etablish that I'm credible: I
can tell you that I have absolutely no intention of doing it

And yet you have greatly increased your credibility with this post.

I disagree. You give him too much credit.


I still

disagree with what you've said, but I can see you know more about what
you're talking about than it seemed before. Before, I thought you were
ignorant and uncurious. Now I see you are merely wrong.

I suspect that is wishful thinking on your part.

 

[David Cressey]

an attempt to make SQL data have an address

Exactly. Literally hundreds of attempts to sell snake oil in c.d.t. can be
reduced to precisely this statement. We've all said variations of the
above, but I've never seen it put so succintly.

As far as the MS Access newsgroups that this discussion is posted to, I
can't speak to how well your summary extends to their mental model. But
many of them seem to write as if
contents as determined by address were the fundamental paradigm of data.

 

[David Cressey]

Personally, I don't take the natural keys out either, so they can still
be used for the deletion.

There are really two issues being discussed in a single discussion here.

The issue of synthetic keys versus natural keys is one issue. The issue of
a composite PK in a junction table, made up of FKs, versus a new simple key
is a separable issue.

Please note that, if the two FKs under discussion both reference synthetic
PKs, all of your arguments concerning the problems of dealing with natural
keys become moot.

If we have three tables, Students, Courses, and Enrollments, where
enrollments is a junction between Students and Courses, we could have a
synthetic key, StudentID for students, and a synthetic key, CourseID, for
Courses.

The question then remains which is simpler. To define enrollments with a
composite key
(StudentID, CourseID), or to define a new synthetic key, EnrollmentID.
Neither of these two solutions uses natural keys.

I prefer to se natural keys whenever possible, but I use synthetic keys
when natural ones just won't do. When do natural keys fail to do the job?
When the poeple who control them are mismanaging them.

 

[David Cressey]

Well, that's just dumb. Checks in code can reduce database round-trips, and
therefore can improve performance, but are not and cannot be a substitute
for constraints on the tables. It is the constraints on the tables that
keeps garbage out of the database.

The idea of keeping garbage out of the database takes on an entirely
different meaning if you are dealing with hundreds of programs written in
COBOL, Java, or anything in between accessing a single Oracle database on
the one hand. On the other hand, if you are a developer creating a self
contained MS Access database cum application (tables, queries, forms,
reports, modules, etc.) all in one file, the same issues arise, but they
are resolved quite differently.

I'm not saying either one is "right" or "wrong". I'm just suggesting why an
objection that makes perfect sense to you and me might be lost on the MS
Access community.

 

[Rick Brandt]

The idea of keeping garbage out of the database takes on an entirely
different meaning if you are dealing with hundreds of programs
written in COBOL, Java, or anything in between accessing a single
Oracle database on the one hand. On the other hand, if you are a
developer creating a self contained MS Access database cum
application (tables, queries, forms, reports, modules, etc.) all in
one file, the same issues arise, but they are resolved quite
differently.

I'm not saying either one is "right" or "wrong". I'm just suggesting
why an objection that makes perfect sense to you and me might be lost
on the MS Access community.

^
some of

I think if a thorough poll was done it would show that the majority of
professional Access developers (those that make their living at it) would agree
that data integrity rules should be enforced by the database engine wherever
that is possible.

The fact is that Access is a tool predominantly for *users*, not developers, and
Microsoft appears determined with each subsequent version to make that more the
case. The majority of changes make it easier to do things incorrectly because
that makes the program easier to use for people who have no idea what they are
doing. Since that group vastly outnumbers the other one can hardly argue with
their logic from a business standpoint.

 

[Brian Selzer]

Since natural keys are data that needs to be managed, this
is an unsurprising claim. I don't throw out the data I'm supposed
to be managing either. Also consider this thread is about junction
tables. Imagine what you would have left if you threw out the
natural key of a junction table: nothing! Just the capriciously
introduced surrogate key in a table by its lonesome self.

Perhaps I've just stumbled into a sanity check for table
design: every projection of a table should have a meaningful
predicate. (Do I hear JOG's ears pricking up?) In a junction
table in which a surrogate key has been introduced, what's
the meaning of the projection of the table over the s.k. column?
Oops!

I think you're jumping the gun, Marshall. Since a surrogate key value is
just a name, what a projection over the s.k. column would leave you with is
a set of names, and the only meaning that can be derived from each element
is that there is an individual that has been so named and due to domain
closure that that individual actually exists.

 

[Sylvain Lafontaine]

Your argument about the use of a DRI WITH ON UPDATE CASCADE is an

Really? I can put my hand on my heart and say I've never seen anyone
suggest it when they cross-post to comp.databases.theory. I don't doubt
it has come up, but I do doubt it is often.

Oh, the word "often" is all relative here. Of course, in a newsgroup about
Access and/or SQL-Server, you won't see it coming very often because these
two databases don't offer support for DRI updating on cyclic relationships.
What you are more likely to see would be people complaining about the
absence of such support in SQL-Server. However, I suppose that many of
those peoples who are making this complaint have probably the use of natural
keys behind their mind (the other strong possibility beeing the use of some
form of replication); so this close the circle. I've also suppose that on
other newsgroups dedicated to systems like Oracle, the discussion about this
point is probably much more heated.

I should also add that if I remember correctly, this one was a feature that
has been promised to be released with SQL-Server 2000 but that it didn't
make the last cut and a lot of people were angry about that. Nowadays, in
regard to the next release of SQL-Server 2008, peoples seem to be more
interested with features such as the integration with .NET and other big
stuff like that than to know if Katmai will offer support for this or not.

First of all, updates to keys should be very rare. A fundamental property
of a well-chosen key is that it is reasonably stable. Imposing the little
self-discipline required to make sure you choose stable keys is
inconsequential when compared to the overall database design effort.

This is the big problem with natural keys. When the theory was first
elaborated, the point was that a natural key never change its value. That
was the point that was making the choice of a natural key on par with the
use of a surrogate key as the primary key of a table. However, like anyone
have discovered with experience, a natural key can change its value under a
set of various circonstances. One could argue that if a key can change its
value, than it's not a natural key but as you know, this argument bring
nothing in regard to help you choosing a natural key.

Now, how it's important the fact that the update to a key should be very
rare? To me, there is a big difference between 0 and 1 time but there is
not between 1 and 1 million times. If you have to put code in order to take
into account the fact that the key can change its value, it should be the
same code if the key change its value one single time for the life of the
database or multiple times each day. In many cases, you are even placed in
the situation where there is a strong possibility that the key will never
change its value a single time for the whole lifetime of the database but
that you must take into account the possibility that it might do so.

Of course, there are many possible solutions: put a lot of DRI/triggers and
other pieces of code; forbid any change (and make the clients unhappy on
many occasions); suggest to delete the records and recreate them from
scratch or even rebuild the whole database; etc.; etc. but why bother with
all these in the first place?

To me, the use of natural keys is like someone bringing me a box full of
Damocles' swords: he would usually tell me to be very careful when I will
put these on the ceiling. Later, when he will come back and see the empty
ceiling and ask me why, I would answer him that I've put the box in the
garbage bin but if he want them, he can bring the box home for free; at the
condition that I'll never see them again. The fact that some theorists like
these swords too is of no interest to me. If they like them, they too can
bring them home for free but at the same condition, that I'll never them
again.

 

[Sylvain Lafontaine]

Most Vociferous Person (MVP)? Well, I suppose that this was true then you
would have earning this little award a long time ago. As for the rest of
your post, you know the old proverb: thefts have the best locks.

--
Sylvain Lafontaine, ing.
MVP - Technologies Virtual-PC
E-mail: sylvain aei ca (fill the blanks, no spam please)

Hi Sylvain,

First, let me thank you for being so kind as to volunteer the information
that you are a Most Vociferous Person (MVP). It does a fair service to the
world when the self-aggrandizing ignorants self-declare that information.

To that, I would add that the increased simplicity of using a surrogate
(or artificial or autonumber) key as the primary key in place of a
composite key is only half their advantage.

At this point, a prudent man would Plonk! you while mentally citing Date's
_Principle of Incoherence_. Never the prudent man, instead, I observe the
absurdity of your suggestion that adding features, structures or
attributes increases simplicity. What nonsense!

The biggest problem that I have with composite keys is that they share
the same fundamental problem as natural keys: using them as the primary
key is allowing the fact that a primary key can change its value over
time. IMHO, a primary key should never be allowed to change its value
once it has been created; a assumption which will forbid the use of a
composite key in many cases.

I find your absolutism foolish suggesting ignorance and/or stupidity.

The design criteria for keys are: uniqueness, irreducibility, simplicity,
stability and familiarity (in no particular order). If any criterion is
absolute, it is uniqueness not stability.


(Of course, if you don't mind to see a primary key changing its

value after its creation then you are not concerned by this argument.).

This is not only a theoritical argument as many interfaces - like
Access - won't like to see a primary key that could change it value.

It is not a theoretical argument at all. You simply regurgitate ignorance
and stupidity.

[remaining nonsense snipped]

Plonk!

 

[David W. Fenton]

(e-mail address removed) wrote in
m:

If the users only access the tables through forms, conforming to
best practices in Access, how are they going to get garbage into
the tables?

What if there's more than one application built on top of the
database?

I, too, agree that one should put as much of the data logic in the
back end as possible.

However, that doesn't mean I use natural keys very often. I'm
definitely opposed to compound keys for any table whose PK will be a
foreign key in another table. It causes myriad problems of all sorts
(been there, done that), and despite its being theoretically
correct, just doesn't work well in practice.

Just consider one scenario:

You need to build criteria for a query-by-form interface. That means
that to query on the PK of a table with a compound PK, you end up
needing to have multiple fields in your WHERE clause. And if you're
querying multiple records in the table with the compound PK, you'll
need a complex nested OR in your WHERE clause.

I know perfectly well that theoretically speaking you're not
supposed to let your application drive the design of your schema,
but this is a case where common sense tells me that following theory
leads to enormously difficult application logic problems.

Natural keys are great for tables with a single-column natural PK.

Otherwise, surrogate keys make building an application substantially
easier.

And, BTW, I would, of course, advocate that any natural key that is
not used as the PK should naturally have a unique index on it.

And any natural key that can't have a unique index (because some
fields need to be Null) was never a candidate for PK in the first
place, and would have to have had uniqueness enforced in the
application in some fashion anyway.

 

[David W. Fenton]

m:

I certainly don't think developers should excuse sloppy RDBMS
design just because they are using access (and of course I'm sure
many of the professionals here wouldn't dream of doing so, despite
others laxness).

What *are* you talking about?

Any mistakes in schema design that you can make in Access, you can
make in any other RDBMS.

I would agree that there are many places that the wizards in Access
and the sample databases encourage sub-optimal practices. But most
professional developers aren't using either wizards or the sample
databases as their models for developing their own applications.

If your impression of Access comes from futzing with it for 10
minutes and from encountering kludged-together apps created by your
company receptionist, then you just haven't a clue what Access
offers, either as an application development platform or as a data
store (using its native Jet engine).

This is a schema question, and that is orthogonal to Access, because
Access is an application development platform. If you use Jet for
your data store, then Jet is relevant to the discussion. But you can
use any data store that offers an ISAM or ADO or ODBC drivers, and
that means all your schema issues are completely divorced from
Access itself.

That you can't seem to keep this distinction clear in your mentions
of Access demonstrates pretty clearly that you are completely
clueless about Access and really aren't in any position to be making
disparaging comments about it.

 

[David W. Fenton]

m:

No probs, although off the top of my head its gonna be a bit
contrived. With an artificial key:

Marriages {id, husband, wife, date}
Kids_from_Marriage {from_id, name, birth}

A query that asks "fetch me all the children whose mother is x"
obviously requires an equijoin, matching Marriages.id and
Kids.from_id. However with the original natural keys:

Marriages {id, husband, wife, date}
Kids_from_Marriage {mother, father, name, birth}

The same query is a simple select. That certainly seems a lot less
complicated to me

Assuming you've got some form of CASCADE UPDATE on your enforced
relationship, that will work.

But it's repeating a huge amount of data, and adding a bunch more
indexes to keep updated. Perhaps these are insignificant issues to
*you* and *your* apps, but my clients' apps (some using Jet, some
using SQL Server, some using MySQL) don't perform so well when you
add in all the overhead.

And it all leaves aside the question of how you know that
husband/wife/date is always going to be unique. I think that on any
given day in the US, there are plenty of marriages in which those
three values will be identical. You could add place. But then, in
large cities, that might not be enough. So use Postal Code in place
of place, and that might do the trick, although in large cities that
might not do it, either.

Given that I can foresee a reasonable possibility of a collision on
this candidate key as currently defined, I'd think long and hard on
whether to use it or not.

And it's one of the main problems any time you're storing data about
people in a data table -- you often lack pieces of the information,
and you run a high risk of collisions between people with the same
names.

And that fact of the real-world entities being modelled makes
finding a natural key that will work as a PK a very hard task.

 

[David W. Fenton]

:

Since natural keys are data that needs to be managed, this
is an unsurprising claim. I don't throw out the data I'm supposed
to be managing either. Also consider this thread is about junction
tables. Imagine what you would have left if you threw out the
natural key of a junction table: nothing! Just the capriciously
introduced surrogate key in a table by its lonesome self.

Perhaps I've just stumbled into a sanity check for table
design: every projection of a table should have a meaningful
predicate. (Do I hear JOG's ears pricking up?) In a junction
table in which a surrogate key has been introduced, what's
the meaning of the projection of the table over the s.k. column?
Oops!

Junction tables that:

1. include nothing but the foreign keys of the tables they are
joining,

AND

2. have no child tables

need not surrogate key.

Since I use surrogate keys in most of my schemas, most junction
tables are two-columns, and those two columns are the PK.

Once I did have a schema where there was a child table to the
junction table, and in that case, I wish I'd had a surrogate key (it
was a pure natural key design, actually, and the worst project I've
ever worked on; no one to blame but myself, as I designed the schema
from scratch), as it made it awfully difficult to work with that
table that was a child of the junction table.