You might as well timestamp it
changelog.com
You might as well timestamp it
1–10 of 205 posts
Re: You might as well timestamp it
#2This 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.
Re: You might as well timestamp it
#3To quote the author: "it depends"
If when something happens needs to fold into your business logic then by all means go for it.
If you're moreso doing it as an audit then logging out the event with it's context is going to be more useful.
Re: You might as well timestamp it
#4It'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 be an issue.
The other thing is introducing of (needless) complexity to the system. It allows to make unwise decisions which otherwise would not be possible if the flag would remain simple boolean and as such stands against KISS system design principles.
Re: You might as well timestamp it
#5To quote the author: "it depends" If when something happens needs to fold into your business logic then by all means go for it. If you're moreso doing it as an audit then logging out the event with it's context is going to be more useful.
> To quote the author: "it depends"
Where do you see this? To quote the article I'm reading: "it doesn’t really depend"
Re: You might as well timestamp it
#6This 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 1970, things can get ... interesting.
Re: You might as well timestamp it
#7This is right. I'm a big fan of this sort of embedded audit metadata wherever it makes sense.
I do wonder when doing stuff like this though, if this really shouldn't be something that the database gives you for free.
I read a few years ago about 'fact based' event stream style databases which store your data as a stream of time ordered ops that can later serve as an audit log, but can be used for even more powerful things such as backups at any point in time, debugging at any point in time, etc.
For practical reasons (i.e. just picking a standard postgres setup to get stuff done) I've never dug into any of these systems or played around with them. Anyone know what the latest and greatest is here? Is there anything I can install on top of postgres to give me this functionality today?
Re: You might as well timestamp it
#8To quote the author: "it depends" If when something happens needs to fold into your business logic then by all means go for it. If you're moreso doing it as an audit then logging out the event with it's context is going to be more useful.
> To quote the author: "it depends" Where do you see this? To quote the article I'm reading: "it doesn’t really depend"
Not op but in the first paragraph he links to another post of his that is all about saying "it depends" often
>https://changelog.com/posts/good-reason-experienced-devs-say...
I'm assuming op is referencing that
(I agree with you here though that in this case he makes a very good argument for "it doesn't really depend")
Re: You might as well timestamp it
#9TLDR don't use a boolean, leave the field empty (NULL) and set a timestamp when should be true.
To be honest a tldr isn't actually needed, the post is both very concise, straight to the point, and convincing.
As per the languages I use more often to query DBs (TS, JS, PHP, Python) I don't see any downside. Evaluating if a variable is empty or not, or it's type, is not "bad", compared to evaluating if a variable is true or false. Even in TypeScript in strict mode, evaluating if a variable with type number is empty or not will result in validly typed code, without any noticeable difference compared to evaluating a variable with type boolean.
Re: You might as well timestamp it
#10This is right. I'm a big fan of this sort of embedded audit metadata wherever it makes sense. I do wonder when doing stuff like this though, if this really shouldn't be something that the database gives you for free. I read a few years ago about 'fact based' event stream style databases which store your data as a stream of time ordered ops that can later serve as an audit log, but can be used for even more powerful t…
I think Datomic[1] works like that
Here's the relevant quote: "Understand how and when changes were made. Datomic stores all history, and lets you query against any point in time. Learn More"