Timeline for Handling deleted users - separate or same table?
Current License: CC BY-SA 3.0
4 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jul 21, 2011 at 3:56 | comment | added | Adrian Shum | Yup much clearer. :) If I am doing that, I would rather make it as user's status change, instead of looking it as physical/logical delete. Though the amount of code will not reduce ( "and isDeleted='0'" vs ' and "state <> 'TERMINATED' ") but everything will look much more reasonable, and it is normal to have different user state too. Periodic-purge of TERMINATED users can be performed too, as suggested in my previous answer) | |
| Jul 21, 2011 at 1:10 | comment | added | Alan Beats | [Clarification1: by 'constantly querying', I meant that we have queries which are like: '... FROM users WHERE isdeleted="0" AND ...'. For example, we may need to fetch all users registered for all meetings on a particular date, so in THAT query, we also have FROM users WHERE isdeleted="0" - does this make my point clearer?] @Adrian | |
| Jul 20, 2011 at 13:26 | history | edited | Peter Turner | CC BY-SA 3.0 |
Edited because I like this answer.
|
| Jul 20, 2011 at 11:43 | history | answered | Adrian Shum | CC BY-SA 3.0 |