Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

You might as well timestamp it

changelog.com

Post reply on HN
Print view View original

131–140 of 205 posts

Re: You might as well timestamp it

#131

Post by zzzeek »

I'm not really down with assigning meaning to NULL. NULL means "unknown", full stop. This is why SQL doesn't like if you compare to NULL using equality, because nothing "equals" NULL.

Similarly wouldn't I want to know when a true value became false? This post seemed very strange in that regard.

Count me in as storing a boolean as a boolean (or as mentioned elsewhere, an enumeration) and if I need auditing on that, then I will also implement proper auditing columns and/or tables to suit my needs.

Re: You might as well timestamp it

#133

Post by jeroenhd »

zzzeek wrote: post #131

I'm not really down with assigning meaning to NULL. NULL means "unknown", full stop. This is why SQL doesn't like if you compare to NULL using equality, because nothing "equals" NULL. Similarly wouldn't I want to know when a true value became false? This post seemed very strange in that regard. Count me in as storing a boolean as a boolean (or as mentioned elsewhere, an enumeration) and if I need auditing on that, th…

The point still stands outside of Javascript, though. Unless you're dealing with very large databases, retrieving a boolean or doing a null check on a timestamp are pretty close operations, especially if you use some kind of frontend to render the data.

Storing a boolean expression ("is published", "marked as read", etc.) as a timestamp can still be valuable. It just happens to be entirely equivalent in Javascript, but in normal, typed languages, the same practice can be used to prepare yourself for debugging a broken application or database later.

I don't think this is a practice that you should just universally apply everywhere, but it's worth considering in a lot of cases where people generally tend to use booleans.

Re: You might as well timestamp it

#134

Post by chadlavi »

davidverhasselt wrote: post #23

There is a downside which I've experienced: if you want a triple-state boolean (null, false, true) then having a boolean column allows for that while a timestamp-as-boolean column does not (you lose the "null" value because that equals `false` in timestamp-as-boolean). Having a distinction between `null` and `false` can be handy for values that are optional or have a dynamic default. If it's `null` you know it is not…

The use cases the blog post is discussing aren't tri-state bools though. Either the user did or did not sign in. Either the version was or was not published. Null and false are equivalent here.

Re: You might as well timestamp it

#135

Post by another-dave »

underwater wrote: post #31
davidverhasselt wrote: post #23

There is a downside which I've experienced: if you want a triple-state boolean (null, false, true) then having a boolean column allows for that while a timestamp-as-boolean column does not (you lose the "null" value because that equals `false` in timestamp-as-boolean). Having a distinction between `null` and `false` can be handy for values that are optional or have a dynamic default. If it's `null` you know it is not…

I'm struggling to think of an example following the OP's example - discrete events that may have not occured yet - where you'd need to differentiate between a certain `false` and an uncertain `null`.

Well the article uses the example of swapping `is_published` for `published_at` — with a boolean you could have:

* NULL — never published (e.g. draft) * true — live now * false — previously live but explicitly unpublished

Which you miss if just a date. Similarly he talks about `is_signed_in` — NULL/true/false let's you model the case where a user has never signed in (e.g. an admin created your account but you've never used it) but NULL/timestamp missed this

Re: You might as well timestamp it

#137

Post by aitkenably »

bob1029 wrote: post #45

I don't like this. Yes, you can alias the true/false fact to null/non-null datetime value, but this is missing the point of domain modeling. The immediate impact of this decision is probably negligible as long as you did not need to store a nullable boolean fact, as opposed to a non-nullable boolean fact. The broader impact of this decision is that you have endorsed a policy of assuming how things will be used in the…

Since you mention domain issues, I’ll also note that all the examples given are tracking system events, not domain events. For domain events, a system timestamp is usually incorrect.

The date something occurs in the real-world can be different from when the data entry was done. If you blindly convert Booleans into timestamps without that differentiation, you’ll end up with misleading data.

Re: You might as well timestamp it

#138

Post by Dah00n »

hallway_monitor wrote: post #129
alpaca128 wrote: post #103

Earlier quoted context omitted.

What you describe calls for an Enum, not a nullable boolean which is just another way of passing a hardcoded magic value carrying an implicit meaning. > a boolean column actually has 3 states, a timestamp only has 2. Going with your logic a timestamp has billions of states, you just have to arbitrarily assign special meanings to certain dates that won't ever be used. Just like using null as another state I wouldn't c…

Your statement is false. Many use cases call for optional bools. The great thing is there is no implicit meaning - it's True, False or Unset. It is true that nulls can be abused but in this case, far more elegant than an enum.

Could you supply an example that an enum wouldn't do as well? How is a bool null, false, true different than an enum with null, false, true?

Edit: grammar

Re: You might as well timestamp it

#139

Post by themulticaster »

PebblesRox wrote: post #122
isbvhodnvemrwvn wrote: post #114

Earlier quoted context omitted.

Well, in browsers there's `HTMLMediaElement.canPlayType()` which returns one of the following strings: - "probably" - "maybe" - "" Reference: https://developer.mozilla.org/en-US/docs/Web/API/HTMLMediaEl...

That's like my washing machine which has a Normal setting, a Standard setting, a Wash setting...

Do you mean as in "If the washing machine has a Wash setting, what does it do if it is not set to Wash?"

Re: You might as well timestamp it

#140

Post by isbvhodnvemrwvn »

themulticaster wrote: post #139
PebblesRox wrote: post #122

Earlier quoted context omitted.

That's like my washing machine which has a Normal setting, a Standard setting, a Wash setting...

Do you mean as in "If the washing machine has a Wash setting, what does it do if it is not set to Wash?"

And what's the difference between normal and standard?
Post reply on HN