#137. Applications should NEVER delete data from a database EVER.

on

  National Security Secret  

#137. Applications should NEVER delete data from a database EVER.

It needs to be an absolute requirement.  Instead of a delete there should be one of the following:

  • Inactivate
  • Disable
  • Mark or flag as deleted (but don't actually delete)
The last item happens to be the definition of the first two.  Now you know what we mean.

Preferably, a database wouldn't support deletes whatsoever.  There's benefit to that beyond preventing data trails from being lost or hidden.

Performance testing becomes built into minimal functionality testing.  It can't be avoided when a database has no way of getting smaller.

Just as helpful: those "Russian" or "Chinese" hackers causing trouble can't compromise databases as easily.  Correctly adding something to a database requires more effort than just removing - assuming the database designer did only the bare minimum.

Should this reveal countless alleged foreign hackers as internal programmers who took shortcuts during development or didn't understand a change they were making... all the better.

We prefer a "sealed database" concept.

Data goes in but never comes back out in its original form.  In fact, queries made against a sealed database only return 2 or 3 possible values:
  • 1
  • 0
  • -1
Those mean 'true', 'false', and 'error'.

So a query against a sealed database might be written as:

DOES [so or so individual] HAVE EMPLOYMENT [at this moment and for 3 months prior] WITHOUT [any bankruptcies for 7 years prior] OR [owns a home]?

The reply could be true, false, or there's a problem.

We don't understand how government provided data could be accessed any other way.


More information will be provided.



Originally posted on 03-31-2023 @ 02:02 PM

Comments

Post a Comment