Sitting in the data science seat, downstream from the application development and trying to gain insights on production data, I completely second this approach. It just gives you more to go on and more ways to validate whether something unexpected is going on.
You might as well timestamp it
11–20 of 205 posts
Re: You might as well timestamp it
#12This seems to only really work in languages that allow null variables/timestamps. I wouldn't really want to have to do comparators to the default value of a timestamp.
> ...default value of a timestamp.
Assuming the timestamp represent a change of state in a contemporary application, I would expect 1970-01-01 0:00:00Z (UNIX epoch +0 seconds) to be unambiguous enough (But that's definitely an engineering constraint to maintain awareness of)
Re: You might as well timestamp it
#13This seems to only really work in languages that allow null variables/timestamps. I wouldn't really want to have to do comparators to the default value of a timestamp.
The author is talking about databases, not programming languages. I do see a different issue, though: The article indeed seems to make no distinction between an absent value and a default timestamp of 0. That limits your database to more or less "now". You cannot really store things about the past. Someone might take such a pattern and fixate it into some kind of library. If then someone else tries to store data from…
That is a very neat and smart improvement!
Re: You might as well timestamp it
#14You might as well version it. Timestamps are relative if different machines set it. Versions are primitive (ie atomic) and always absolute, and usually the best way to treat concurrency.
Re: You might as well timestamp it
#15This reminds me of tricks in JavaScript such as using !! to convert values to Boolean: it’s clever, “idiomatic” and save a few characters, but it’s not self explanatory to someone not familiar with the idioms
Re: You might as well timestamp it
#16Indeed, this is a bit of wisdom I first encountered when playing with Django and seeing others do it. You can still see it in a couple of the many soft-delete packages available on PyPI, in the form of deleted or deleted_at fields with DateTimeFields. (Though admittedly, I'm pretty out of date on Django these days.)
(Though it is worth noting that you sort-of get this for free if you implement a scheme with 'revisioned' data, or a database that simply has that as a feature. But, it's still useful to just have this additional bit of information handy, if nothing else.)
Re: You might as well timestamp it
#17It's a very neat idea that I'll consider in the future however I have some concerns about it. One thing is about the database design. I remember lecturer proclaiming that models with many nullable relations is: - bad design - performance risk - might mess with indexing I haven't verified this knowledge in many years, to I'm not sure if that point still stands, also in wake of not optimizing pre-mature this might not…
Yes, nullable relations are harder to work with, especially with ON DELETE CASCADE and checking if another table contains a row based on a nullable column. However, this is about booleans, so they werent used in relations to begin with.
The indexing in this case could be a bit less performant but probably neglegable.
Re: You might as well timestamp it
#18It's a very neat idea that I'll consider in the future however I have some concerns about it. One thing is about the database design. I remember lecturer proclaiming that models with many nullable relations is: - bad design - performance risk - might mess with indexing I haven't verified this knowledge in many years, to I'm not sure if that point still stands, also in wake of not optimizing pre-mature this might not…
The OP doesn't talk about *nullable relations*, which I agree is a sign of bad desing
Re: You might as well timestamp it
#19I've yet to find a case where using a timestamp over a boolean hasn't been the better option.
This is because turning a boolean on is an event so it'll always have a timestamp.
Sometimes it's useful to know when this event happened.
The only exception I can think of is if for some reason you're trying to save on bytes, which in this day and age, especially true for web applications, this is practically never the case.
Re: You might as well timestamp it
#20[deleted]