-1

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.

7

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.

  • 1
    now I feel like we can't start our next project without at least considering a CRUSHJWERP architecture – david.libremone Jun 22 '16 at 12:51
8

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.

  • 2
    Simple and clear. As long a delete act like a delete for the user, it's a delete, duck typing CRUD^^ – Walfrat Jun 22 '16 at 12:47
0

"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?

  • In most application that have data disabled instead of deleted. Some will be effectively purge, however this may not be done by the application itself, but by a maintenance operation, which his outside the CRUD services of the application. – Walfrat Jun 22 '16 at 12:49
  • I've tweaked the wording accordingly – david.libremone Jun 22 '16 at 12:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.