In my 15+ years of web development, there are very few things I can say are unequivocally a good idea. It almost always does depend. Storing timestamps instead of booleans, however, is one of those things I can go out on a limb and say it doesn’t really depend all that much. You might as well timestamp it. There are pl...
  • key@lemmy.keychat.orgEnglish
    2·
    1 year ago

    Only really makes any sense for flags that go from false to true and don’t go back often. And even then it has huge semantic cost. How do you distinguish a “boolean timestamp” from an actual timestamp? Is “modified at” a flag indicating a pending modification or a timestamp when it was last modified?

    Much better to just have two columns, so e.g. you can see “enabled” and an 'enabled_date" that indicates when you last enabled/disabled the entity.

    • Domi@lemmy.secnd.meEnglish
      1·
      1 year ago

      Much better to just have two columns, so e.g. you can see “enabled” and an 'enabled_date" that indicates when you last enabled/disabled the entity.

      That sounds good until you realize you now have two sources of truth, do you trust enabled or enabled_date? If you really want to go this route enabled should be a virtual field that checks enabled_date in the background so you can have the boolean semantics but still keep a single field.

      I also used booleans a lot previously but since using Laravel I have come to enjoy the updated_at, created_at and deleted_at fields that it automatically creates and I follow this format as well now if I need more.