201–205 of 205 posts
Earlier quoted context omitted.
I don't think it's elegant at all. Especially in SQL dialects where you need to check null state separately from false. So much bug potential...
With an enum you’d have to check the unset state separate as well.
Earlier quoted context omitted.
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
Earlier quoted context omitted.
The OP does not talk about events, OP talks about state and when it was set. There's no where in the article that OP restricts themselves to discrete events that may or may not have occured.
I'm not understanding the distinction. The only thing you get out of this schema is knowing what happened (implicitly defined by the field), whether it's happened yet, and when it happened. That feels like an event to me. Fields where there isn't an discrete event don't work. E.g. is_dog_owner can become adopted_dog_at, but is_dog_lover can't become loved_dogs_at. I'd actually even argue that this is not storing stat…
Earlier quoted context omitted.
IMO if you’re going this route, may as well just implement a snowflake clone and get the best of all worlds.
Re: Snowflake clone I would humbly invite you to read the note in the KSUID Github, namely: *To fit into a 64-bit number space, Snowflake IDs and its derivatives require coordination to avoid collisions, which significantly increases the deployment complexity and operational burden.* Therefore KSUID remains the best option.
I would argue that doubling your key-space in the case of KSUIDs may have just as much of an impact as coordinating node ids in the case of snowflake (and in fact the snowflake technique only runs into coordination problems when you're at pretty extreme scale).
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.
Ditto for database design too