So this site says: "All tables in a relational database should have a primary key". Here it also says that every table should have a primary key.

But if I look here and here they say that tables that contain only foreign keys are okay.

So who is right? And which would be the correct answer under a university setting?

  • Technically it is possible. And I don't know of a theoretical must. But it might get you into trouble when a table has no (primary) key as a situation might come where you cannot definitely address a row without it but you need to. But it seems to me you're mixing things up a little anyway. In the question you linked (twice), that you think gives an OK, the OP does want to define a primary key on the table. They just ask if an extra column (surrogate key) is needed or if it is OK to designate the two columns that already are a key as primary key. – sticky bit Jul 25 '19 at 20:53
  • 2
    None of the linked questions and answer say that it should be good to have a table without a PK. – ypercubeᵀᴹ Jul 25 '19 at 22:15
  • 2
    Your “But.. “ links only discuss whether a map table is OK to have a composite primary key vs. a single-column surrogate primary key. – ypercubeᵀᴹ Jul 25 '19 at 22:18

I love that your question includes the qualifier "under a university setting." It just highlights that there is a difference in theory and practice.

We have a few tables in production that don't have an indexed primary key and they are lightning fast to read. We do have indexes on the columns that we read on and join from. But in the University, they probably want you to say always include a primary key column.

| improve this answer | |

Not the answer you're looking for? Browse other questions tagged or ask your own question.