I always use an autonumber PK and a unique index set on the two FK fields [sic]. Why? No particular good reason. One of my database rules is that all tables have an autonumber primary key [sic].

You add redundancy to a schema and never thought about it? If you had
gone thru the Normalization process, this would stick out as a
fundamental design error immediately. You have not been writing SQL;
you are faking a sequential file system in SQL and even say "field"
instead of "column" -- huge conceptual and implementation differences!

It's also slightly easier to delete the record [sic: rows are not records!] in code.

How do you know that you got the right entity? Don't you have a text
editor if a little extra typing is that serious a problem that you
need to add errors and overhead to your SQL?


Now if I was to have a child table [sic: that terms comes from Network DBs; did you used to program in IMS?] from the junction table [sic: did you mean a table that models a relationship among many entities? Or a multi-way pointer structure as in an Network DB?] then I would absolutely use a autonumber primary key [sic: it cannot be a key by definition] for ease of use when designing queries, forms and reports.

I hope that you are not designing forms and reports in the database.
That is a job for the front. Now, in the old days, when COBOL, et al
had a file system, we had to do it this -- monolithic architecture vs
tiered architecture.

The theorists will argue. I don't care.

Would you say the same thing to an accountant who wanted the books to
balance ??