I’d go further to suggest an audit log of all changes.
In my industry it’s required for most apps I work in, so I’m always surprised when I come across a scenario where data is changed and we don’t know who/when.
This kind of thing makes me think applications should be using log-structured databases. You get history and auditing for free. The downsides are quite obvious though; few good libraries/databases for it, and they could get quite bloated.
Throw in changing schemas that need to be kept in lock step with the data and you have an endless source of nightmares.
What did you think the value of row A column B would be on date Y at date Z, noting that the schema split the column into three separate columns at dates Y.0 and Y.1?
The correct answer is of course updating your resume.
Ah, the world where storing a string vs a Boolean has “negligible” overhead. Whereas my inner bean-counter immediately starts hopping up and down yelling about heap allocations and locality of reference, and even if you store the time stamp as a double that’s 8 bytes vs 1 and do you know the size of a cache line…?
Not saying one world is truer or better, of course! I wasn’t the one stating a practice that’s “almost always” right. I’m just amused at how people think their domains are all there is (like the web-dev folks who can’t believe SQLite is more widely deployed than Postgres.)
If you are working with those restraints then it’s pretty obvious that his won’t work for you, but I think it’s very obvious that this post wasn’t aimed at you.
Yeah. “Web development” features in the very first sentence of the post, and I’m sure the blog author knows their audience. Comments like the one you replied to don’t elevate the discussion whatsoever. (cf. @dbove’s, which is germane and an interesting discussion point.)
Sure, say if published_at != nil or whatever the equivalent idiomatic truth test in your language of choice is.
The article maybe spends too much time on the ergonomics in JavaScript with the large code block, drawing attention away from its whole point: that you’re better off storing a nullable timestamp than a boolean in most cases.
How you then test that field is kind of secondary to the data modelling concern. (“And you can pretty this up with a helper function called isPublished() which checks the published_at attribute.”)
SQLite does not have a storage class set aside for storing dates and/or times. Instead, the built-in Date And Time Functions of SQLite are capable of storing dates and times as TEXT, REAL, or INTEGER values:
TEXT as ISO8601 strings (“YYYY-MM-DD HH:MM:SS.SSS”).
REAL as Julian day numbers, the number of days since noon in Greenwich on November 24, 4714 B.C. according to the proleptic Gregorian calendar.
INTEGER as Unix Time, the number of seconds since 1970-01-01 00:00:00 UTC.
Applications can chose to store dates and times in any of these formats and freely convert between formats using the built-in date and time functions.
What if you want to keep track of when your field became false, too? Would you then have both hidden_at and shown_at? What if you wanted to keep track of every time it was hidden or shown, not just the most recent happening of each?
The proposal doesn’t quite extrapolate out cleanly, but, in fairness, I see the point that the “NULL or timestamp” communicates more information than “false or true”.
I’d go further to suggest an audit log of all changes.
In my industry it’s required for most apps I work in, so I’m always surprised when I come across a scenario where data is changed and we don’t know who/when.
This kind of thing makes me think applications should be using log-structured databases. You get history and auditing for free. The downsides are quite obvious though; few good libraries/databases for it, and they could get quite bloated.
Not to mention that out of all the places I’ve worked in precisely none got temporal data right: https://en.wikipedia.org/wiki/Temporal_database#Using_three_axes:_valid_time,_decision_time,_and_transaction_time
Throw in changing schemas that need to be kept in lock step with the data and you have an endless source of nightmares.
The correct answer is of course updating your resume.
I LOLed at that. Thanks for making my morning!
Ah, the world where storing a string vs a Boolean has “negligible” overhead. Whereas my inner bean-counter immediately starts hopping up and down yelling about heap allocations and locality of reference, and even if you store the time stamp as a double that’s 8 bytes vs 1 and do you know the size of a cache line…?
Not saying one world is truer or better, of course! I wasn’t the one stating a practice that’s “almost always” right. I’m just amused at how people think their domains are all there is (like the web-dev folks who can’t believe SQLite is more widely deployed than Postgres.)
If you are working with those restraints then it’s pretty obvious that his won’t work for you, but I think it’s very obvious that this post wasn’t aimed at you.
Yeah. “Web development” features in the very first sentence of the post, and I’m sure the blog author knows their audience. Comments like the one you replied to don’t elevate the discussion whatsoever. (cf. @dbove’s, which is germane and an interesting discussion point.)
there are tons of other web development languages where people would cringe at:
that’s… not how types should work, really (I know that in Python it could also be None, but in this case I find this a horrible combo of naming+type)
Sure, say
if published_at != nilor whatever the equivalent idiomatic truth test in your language of choice is.The article maybe spends too much time on the ergonomics in JavaScript with the large code block, drawing attention away from its whole point: that you’re better off storing a nullable timestamp than a boolean in most cases.
How you then test that field is kind of secondary to the data modelling concern. (“And you can pretty this up with a helper function called
isPublished()which checks thepublished_atattribute.”)Mea culpa — by the time I reached the end I must’ve forgotten the first sentence, “ In my 15+ years of web development…” 😫
A string? Is that a typo?
If you’re using sqlite3, it is. https://www.sqlite.org/datatype3.html explains:
And sure enough:
Well, wait.
What if you want to keep track of when your field became
false, too? Would you then have bothhidden_atandshown_at? What if you wanted to keep track of every time it was hidden or shown, not just the most recent happening of each?The proposal doesn’t quite extrapolate out cleanly, but, in fairness, I see the point that the “NULL or timestamp” communicates more information than “false or true”.