I want to be clear when discussing an implementation that we're using soft-deletes (not immediately removing data from the database). What can I call our approach? The best I have is "CRUD with soft delete", just "CRU", or CRUH (create, read, update, hide), which afaik is a neologism.
You call it "CRUD."
Designating an app as a CRUD app is meant to indicate that a lot of its core functions center around common record-management tasks--the eponymous create, read, update, and delete. "CRUD" is not, however, meant to completely describe the app.
CRUD apps have a range of activities, variations, and implementations. Some soft-delete, some hard. They variously write data to JSON, YAML, CSV, and 1,000 other file formats; others write to database backends. They're written in different languages. Some are terminal apps, others are graphical- or web-interfaced. Some add search, browse, report, purge, and other features.
If you start trying to encode all these choices into the acronym, you lose sight of the commonality. Instead of identifying with a common workflow, you're describing all the ways the app varies from common choices, and you end up with horrible sound-and-fury acronyms like CRUSHJW that no one but you will understand. Because you just had to signal hide-not-delete, yes-it-has-search-too, it-writes-to-JSON, and web-front-end. But wait! It's written in Python, has significant reporting and error correction features. Gotta mention those, so: CRUSHJWERP! So much better!
No, not really. The CRUD acronym is meant to identify an app as belonging to a broad family of record-managing apps that most developers instantly recognize and understand. It's not meant to encode all its variations and extensions. In addition to the fanciful goes-off-the-rails example above, the importance of simplicity and commonality is demonstrated by the historical fact that even extremely common additional functions (e.g. search) have not made it into the common acronym.
Delete is delete. If you are hiding the data behind a flag, or removing it from your DB, or writing an archive to another table, or generating a transaction-log style audit entry, or wiping the bits off the disk a thousand times using randomly encrypted values... it doesn't matter. You've still deleted the data from the user's view. As far as a business process is concerned, the data is gone even if you've still got a copy of it hanging around.
Consider the alternative if you don't think of the initial user-initiated delete as a delete:
so when the user clicks delete, its deleted right?
No we just set a flag to hide it from view until the disposal process runs every 30 days.
Then its deleted?
No, then its moved to an archive location for the regulatory 7 years.
Then it gets deleted?
No, then it ends up on the backup discs that get sent to the storage facility.
But then it gets deleted, surely?
Erm, well, I suppose so, but nobody's worked here long enough to find out.
"Never" implies a very long time.
Are you even allowed to keep data that long?
What are your Data Retention Policies?
Do you hold any Personally Identifiable Information (PII), which must be kept up to date; holding this indefinitely (and not maintaining it) could get you into all sorts of [legal] difficulties.
And then, of course, there's the simple cost of keeping all of this "stuff" forever:
- primary data disks,
- mirror disks,
- backup media and storage thereof,
- [ever] more powerful machines to run your database as its main tables just keep growing,
- and so on ...
Who's going to pay for all that?