Hi folks.
When designing persistent entities, do you prefer to use quot;deletedquot; flag or perform real db deletion ?
Later seems cleaner and more straightforward at first, but it seems to me that for sake of archiving past actions and their statistical review, which is common thing in every proper app, one has to have info about deleted entities, and best way to do it is simply to still have it in db, right? And that means having special flag, such as quot;deletedquot;...
Regards,
Vjeran
Well said! Third possibility is moving a deleted object to a history. But as you already said, if it is required that the element stayes where it is, then the lifecycle state of that object (row,tuple) needs surely to be added.
Quite well works a combination of history and lifecycle states. Object (row,tuple) is put into inactive(delete, shadow, dead, sleep etc..) state and after a certain time (month or more) the object is moved to a history (table, file, log, garbage(?)) and the row representing the object in the original table gets removed. This is a very common technic for workflow systems.
There are workflow patterns out there, but saidly I don't have a resource for you, maybe some others have... .Cheers,
Martin (Kersten)
And I guess that good practice would be to have this deleted field accessors with private-package visibility, thus to be seen only inside UserManager service (of course, if ORM library allows that, fortunately Hibernate does). |
Post at 2011-4-15 16:41
| This Author's Posts Only
