Should a single-row summary table have a primary key?

Question

Say you've got a summary table that's meant to have only one row (storing a row of statistics about another table). In this case I'm using InnoDB so that I can update it as well as the table it's meant to contain a summary of transactionally. Should I make this table have a primary key? If so, what, just a tinyint that's always equal to 1?

Answer 1

I never bother in cases like these. The PK is used to differentiate from other records and in this case there are none.

Answer 2

I think you should, you don't know whether in the future you could be using the same table for storing statistics for other tables, that seems a good place to store'em, then you will need to identify each row of the table.

Answer 3

What if you plan to extend this table? It might make some sense to have a key defined. Again, it's just an opinion and not a necessity in your case.

Answer 4

I would not introduce a PK at the moment. If you ever decide to use this table for other records as well, just refactor and add a new row (as you would probably need anyway) (Premature optimazation). There is yet one reason to add such a PK: if you use a framework that cannot update a record without having a PK that identifies the record.

Answer 5

InnoDB will create a hidden primary key for you if you don't supply one.

It will sometimes be easier to have access to this key, as

INSERT
...
ON DUPLICATE KEY UPDATE

can be used to update this table regardless of does it already have values or not.

And yes, just use a constant 1.

Answer 6

I would put an identity column on it (I don't know what the InnoDB equivalent is). It's harmless to do so and will make it much easier to select or delete a specific row if you ever need to.

Answer 7

I'm going to offer a devil's advocate answer, given that most other answers are "no you don't need one."

A primary key constraint assures that you don't get rows that have duplicate values in the column(s) you apply the constraint to. You said you intend this table to have a single row, so why wouldn't you declare the constraint? It could help prevent duplicates, which is what you want.