`active' flag or not?

Question

OK, so practically every database based application has to deal with \"non-active\" records. Either, soft-deletions or marking something as \"to be ignored\". I\'m curious a

Answer 1

Regarding indexing the boolean, why not:

ALTER TABLE users ADD INDEX index_users_on_active (id, active) ;  

Would that not improve the search?
However I don't know how much of that answer depends on the platform.

Answer 2

We use active flags quite often. If your database is going to be very large, I could see the value in migrating inactive values to a separate table, though.

You would then only require a union of the tables when someone wants to see all records, active or inactive.

Answer 3

The active flag is sort of ugly, but it is simple and works well.

You could move them to another table as you suggested. I'd suggest looking at the percentage of active / inactive records. If you have over 20 or 30 % inactive records, then you might consider moving them elsewhere. Otherwise, it's not a big deal.

Answer 4

The situation really dictates the solution, methinks:

If the table contains users, then several "flag" fields could be used. One for Deleted, Disabled etc. Or if space is an issue, then a flag for disabled would suffice, and then actually deleting the row if they have been deleted.

It also depends on policies for storing data. If there are policies for keeping data archived, then a separate table would most likely be necessary after any great length of time.

Answer 5

We use both methods for dealing with inactive records. The method we use is dependent upon the situation. For records that are essentially lookup values, we use the Active bit field. This allows us to deactivate entries so they wont be used, but also allows us to maintain data integrity with relations.

We use the "move to separation table" method where the data is no longer needed and the data is not part of a relation.

Answer 6

In most cases a binary field indicating deletion is sufficient. Often there is a clean up mechanism that will remove those deleted records after a certain amount of time, so you may wish to start the schema with a deleted timestamp.