Trying to convince my team that is not a good idea to have “inbox, sent, read, deleted” as options in a “status” column for an internal messaging system.

  • 0
    @alexbrooklyn they are not but we are using laravel and I told them that laravel comes with a timestamp read_at column in the default notifications table and we could follow that standard on our internal mail, then instead of a status column have a category or dir column for inbox/sent/trash but I was having a hard time convincing them it’s a cleaner approach than the universal status columb that they were thinking on possibly using for tags too
  • 0
    "archived" would probably fit better than "deleted" :p
  • 0
    Humm, lots more context to really know what is up.
  • 2
    Entity relationship diagram.

    When I understand it correctly, your team ist denormalizing a database table...

    And creating a wonderful enumeration of everything in one field - tag, folder structure (eg inbox), status (eg deleted)...

    Usually this ends in an amazing clusterfuck.
  • 1
    Learned the hard way a while back that you almost never want to truly delete data. And that setting a Boolean to indicate deleted items from non deleted ones is usually the way to go. Inevitably customers and users expect to be able to retrieve deleted data and get upset if they cannot
Add Comment