Home/ Questions/Q 4038596
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-20T12:29:33+00:00

I have many tables where data needs to be marked for deletion but not

  • 0

I have many tables where data needs to be “marked for deletion” but not deleted, or toggle between published and hidden data.

Most intuitive way to handle these cases is to add a column in the database deleted int(1) or public int(1). This raises the concern of not forgetting to specify WHERE deleted=0 for each and every time that table is being accessed.

I considered overcoming this by creating duplicate tables for deleted/unpublished data such as article => article_deleted and moving the data instead of deleting it. This provides with 2 issues:

  1. Foreign key constraints end up being extremely annoying to maintain
  2. Number of tables with hidden content doubles (in my case ~20 becomes ~40 tables)

My last idea is to create a duplicate of the entire database called unreleased and migrate data there.

My question isn’t about safety of the data management, but more of – what is the right way of doing it from the beginning?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    I have run into this exact issue before and I think it is a bad idea to create an unnecessarily cumbersome DB because you are afraid of bad code.

    I think it would be a better idea to do thorough testing on your Test server before you release to production. Even I was tripped up by the “Deleted” column a few times when I first encountered it but I eventually caught on, and if you have a proper Dev/Test/Production environment you should be fine.

    In summary, keep the delete column and demand more from your coders.

    UPDATE:

    Alternatively you could create a view that only pulls the records that aren’t deleted and make sure everyone uses that for select queries.

    • 0