8 ms·
It makes sense if you know you will always have exactly one record for that date. If there’s any circumstance or possible future where you might end up with mul
by apothegm 3y ago
It makes sense if you know you will always have exactly one record for that date. If there’s any circumstance or possible future where you might end up with multiple, then don’t. Also consider any implications of that for foreign keys referencing that table.
There’s also nothing wrong with using an integer or UUID PK as an additional field even on a table that has another field that would make a natural primary key.
Date as primary key is a pattern sometimes used in star schemas for OLAP databases, though separate y/m/d tables are more common afaik.
- LorenzoGood 3y agoThe current schema is for a newsletter, where data needs to be stored for each individual day, but only one record needs to be created. I just realized that I can have a year, week, and day of week integer instead.
- chanks 3y agoYou can, but that won't protect you against invalid dates like an actual date type will.
- jmye 3y agoWhat if you had to send a second version on a given day? Let’s say 90% of your content didn’t populate. You might want to send a 12/28/2023b version - would you want to capture both? Feels like there are better options for this use case, with little effort. I guess, is there a reason not use an auto-incrementing int? Serious question, maybe there’s some reason that’s a bad practice that I’m not aware of.