4 ms·
> Instead of keeping deleted data in the same tables from which it was deleted from, there can be a new relation specifically for storing all deleted data The
by adrianmsmith 4y ago
> Instead of keeping deleted data in the same tables from which it was deleted from, there can be a new relation specifically for storing all deleted data
The disadvantage of this is that if you ever do want to access this "deleted" data, e.g. in admin or compliance tools, you now have to do it in two different ways, one way for the main data and a different way in case the data has been "deleted".
The article asserts you'll never need to "undelete" the data. So they're presenting a solution with that assumption, fair enough. Without that assumption, however, moving the data back from an archive table becomes a pain, and if there are any unique constraints e.g. on username or email address, you'll have a problem if you've moved the data out of the main table and another user has used that username or email address.
- Terr_ 4y ago> The article asserts you'll never need to "undelete" the data. IMO it's worth distinguishing between (A) some kind of "click to undelete" feature versus (B) simply having that old-data conveniently exposed for a developer to manually-edit things or craft database-change scripts. In practice I've only ever seen the latter get used, because it requires a developer to figure out how the heck to get "the parts that matter" back while preserving the integrity of other newer data and obeying certain business-rules.
- layer8 4y ago> now have to do it in two different ways Use a view. > if there are any unique constraints e.g. on username or email address Have those in a dedicated table where they aren’t deleted, and add a synthetic key referenced by the other tables.