3 ms·
Timestamps needs to come with a huge warning. If you want to have a created_at timestamp for every record, go for it. HOWEVER be very, very careful about how yo
by blacktriangle 5y ago
Timestamps needs to come with a huge warning. If you want to have a created_at timestamp for every record, go for it. HOWEVER be very, very careful about how you use this field. The semantics of created_at are the time at which the record entered the database, that it is, nothing more, nothing less. Trying to use created_at to represent something that happened in the real world bites so many developers. Users will want to tweak the value of the field since there was a delay between the event occuring and the event getting input into the system. Also once you start supporting data imports, backups, and restores, its clear that created_at has nothing to do with when the event was actually created.
Honestly I still lean away from automated timestamps just because the knowledge of when a record entered the database is not that useful and the danger of some developer using the field incorrectly is too high.
created_at/update_at are nowhere near a proper logging solution and just give developers the illusion that they have one.
- andrei_says_ 5y agoWhat are some approaches that remedy this?
- blacktriangle 5y agoFirst, I'd rename the column to something like "record_created_at" to empahsize its the recording of the record and not the actual creation date. Second, if I was going to do a default version, I would probably use two fields, the above record_created_at and an additional "created_at" field. By default they would be the same, however the understanding would be that created_at is potentially available to the user, settable by import, and record_created_at should be treated as immutable.