While I’ve been working with querying SQL databases for a while, I’m still quite the novice at actually building good tables. One thing I often struggle is with primary keys.
In a table I’m creating now for logging errors on some alarm equipment, I need 5 columns.
The park and code columns uniquely identifies a site (although the park column is atm. not used). Then there is a serial column identifying the equipment in question, and an error containing the error code. Lastly there is a timestamp for when an error is logged.
Each site have several different pieces of equipment, and an piece of equipment may report several errors. When an error is corrected, the row is removed from the table.
Thus to uniquely identify an error, we need to check park, code, serial and fault.
All of these seems like good candidates for indexes based on the queries likely to be run. However it doesn’t seem right to me to define all of these as an combined primary key, they are after all almost all the columns in the table!
I’ve several times struggled with similar problems, and I’ve never felt I’ve found a good solution. Anyone can suggest some good practices for tables like this, where most (or even all) the columns are needed to uniquely identify a row?
A lot of people will just tell you to add an id number to that table, and make it the primary key.
I’m not one of those people.
If the columns {park, code, serial, fault} are necessary to uniquely identify a row, and thereby to prevent duplicates, then the dbms needs to know that. You inform the dbms of that requirement in one of two ways.
In some circumstances, it makes sense to use a smaller surrogate key (an id number) as the primary key. That doesn’t relieve you of the responsibility for informing the dbms of the true state of affairs. (With
NOT NULL UNIQUE (park, code, serial, fault).) I don’t think this applies to your situation, though.