3 ms·
Why repeat yourself? If you can have an expression-valued column, do that. For expiration it's essential that it be able to happen at the scheduled time (when
by cryptonector 4y ago
Why repeat yourself? If you can have an expression-valued column, do that.
For expiration it's essential that it be able to happen at the scheduled time (when it is scheduled anyways) without having to execute a transaction at that time.
- Retric 4y agoIt’s fine for a DB be the source of truth as long as it’s the ultimate arbiter of what’s going on, but any kind of real world event has dependencies outside of the databases control. A digital rental works as a pure time stamp in a DB, a car rental however can’t be rented out to the next person simply because the last persons rental period ended as you might not physically have the car etc.
- Dylan16807 4y agoThe return of the car should have its own entry, separate from when the rental expires. It doesn't mean you shouldn't have a an expiration field.
- Retric 4y agoThe point is the time stamp* has minimal value in the system. It’s very tempting to tie various bits of business logic directly to that specific time stamp, but doing so is almost always a mistake instead you might want say a report for in_customers_hands and over 4 hours late or whatever. The system directly doing stuff based on time stamps is a great way to get sued from regular data entry errors. One such case recently cost Hertz a $168 million payout and a lot of bad publicity. *Of course it should also be calculated rather than being a numeric value in a table somewhere, but that’s another story.