Is it a bad idea to make a count the primary key?

Question

Just thinking about database design issues. Suppose i have a table like this:

CREATE TABLE LEGACYD.CV_PLSQL_COUNT 
(
    RUN_DTTM  DATE NOT NULL,
    TABLE_NAME VARCHAR (80) NOT NULL,
    COUNT Number(50) PRIMARY KEY
);

Is that a bad idea - to make the COUNT a PRIMARY KEY ? Generally, how should I make the decision of what is a primry key?

Answer 1

Is that a bad idea - to make the COUNT a PRIMARY KEY ? Generally, how should I make the decision of what is a primry key?

Candidate keys are based on functional dependencies. A primary key is one of the candidate keys. There's no formal way to look at a set of candidate keys and say, "This one must be the primary key." That decision is based on practical matters, not on formal logic.

Your table structure tells us these things.

• COUNT is unique. No matter how many rows this table has, you'll never find two rows that have the same value for COUNT.
• COUNT determines TABLE_NAME. That is, given a value for COUNT, we will forever find one and only one value for TABLE_NAME.
• TABLE_NAME is not unique. We expect to find several rows that have the same value for TABLE_NAME.
• COUNT determines RUN_DTTM. That is, given a value for COUNT, we will forever find one and only one value for RUN_DTTM.
• RUN_DTTM is not unique. We expect to find several rows that have the same value for RUN_DTTM.
• The combination of TABLE_NAME and RUN_DTTM is not unique. We expect to find several rows that have the same values for TABLE_NAME and RUN_DTTM in a single row.
• There are no other determinants. That means that given a value for TABLE_NAME, we'll find multiple unrelated values for COUNT and RUN_DTTM. Likewise, if we're given a value for RUN_DTTM, or values for the pair of columns {TABLE_NAME, RUN_DTTM}.

If all those things are true, then COUNT might be a good primary key. But I doubt that all those things are true.

Based only on the column names--a risky way to proceed--I think it's far more likely that the only candidate key is {TABLE_NAME, RUN_DTTM}. I think it's also likely that either RUN_DTTM is misnamed, or RUN_DTTM has the wrong data type. If it's a date, you probably meant to name it RUN_DT; if it's a timestamp, the data type should be TIMESTAMP.