Should a log table get an id field or primary key?

Should I remove the id field?

I would recommend keeping it.

You may not need the field now, but in the future, it can really help you out -- what if you need to store details of the files for each log entry?

I don't know how large this table will get and how quickly, but adding a column to a large table is typically an expensive operation. If the table is relatively small, then it's not a big deal to keep in terms of storage space. IMO, keep the column and save a potential headache later.

Should I have a primary key on either messageId or exportedDateTime or both?

It doesn't sound like messageId alone would be unique in this table (though I could be wrong), and creating uniqueness on a date/time column alone can potentially create duplicates (and hence errors). The only option left is a 2-column key, which is not particularly appealing given the scenario I set out above.

---

Essentially, my point of this answer is that keeping the column is not a big deal (I'm assuming), but needing it later may be a big deal and/or require extra work to put it back.

• If you don't have joins on this table, no updates and no deletions, then you don't need keys at all.

• If this is not the case, and messageId is unique, then you can make it a primary key.

• If it's not unique, but (messageId, exportedDateTime) is, then make this a composite primary key.

• If even the (messageId, exportedDateTime) combination can give duplicates and updates and deletes might be needed (say to remove accidentally inserted rows), you'd better leave the id field as is.