2

I'm building a system using a document type database. The system has users. I was told that in production it is best to avoid making outright deletes. I understand the convention is to either mark users as deleted or to transfer them to a deleted table in a RDBMS.

For document type databases what is the convention? I can mark the users as deleted very easily, but then what happens if the user attempts to re-register with the same account info?

Since their email address is supposed to be unique, the user would be prevented from making a new account. how can this be avoided?

EDIT: I was asked to clarify my goals. I want to, allow users to 'delete'/'close' their account.

  • In doing so their accounts should no longer be accessible.

  • The user should not be allowed to sign in using it. Additionally the account should not be able to be used to perform any additional tasks in the service.

  • All of the database changes made as a result of the account should persist. IE, it would be detrimental to the service to remove any data posted or logs created related to the account.

We are attempting to build a HIPAA compliant service which means that access logs must be enforced. I interpret that to mean that the full data of an user who has access to sensitive user information needs to be maintained in

Improve this question

1 Answer 1

Reset to default
5

With an actual delete what happens on a re-register is that a new user is created, likely with a new unique id number even if the email is the same. And unless you get a better explanation of why they don't want to delete users that's what you'll still end up doing.

Just a few possible reasons to not delete: A simple desire to be non destructive so long as your storage has capacity, minimizing data entry because re-registering occurs frequently, data mining, but most insidious is a system design that can't tolerate deletes because information has been copied to a place beyond the delete and forever needs a record, even if marked deleted, to point back to.

You need to understand why they told you this. What problems are created when you delete. And flat out ask them what should be done when someone re-registers. They may already have a plan for that. Don't accept their answer on it's face. Make sure you understand it. Keep asking till you do.

In fact, ask them why about 5 times.

Improve this answer
7
  • I guess the way I said it made it sound like I am dissatisfied with the reasoning. I know for sure that I don't want user accounts deletes to be destructive since I would want check it to gather data in the future. The system doesn't yet exist in any form that would break anything if the deletes are destructive. I am enforcing uniqueness on the email address in my database (mongodb). Are you recommending that the email address uniqueness not be enforced at the database level but a bit higher up the stack?
    – xerotolerant
    Commented Jun 29, 2017 at 14:21
  • 1
    In that case what I recommend is that you give some critical thought as to what you want "deleting" to mean. A delete is a mechanical database function. What you need to sort out is what behavior you want to present. Behaviors that are usually associated with a mechanical delete are: Not showing up in some lists. Not preventing new users with duplicate information. Causing visible defects such as associations to the missing record. By not actually deleting the record you are free to choose only leave some of those behaviors the same. "delete" might even be the wrong word, "withdraw"?
    – candied_orange
    Commented Jun 29, 2017 at 14:47
  • Hmm. Didn't think of that. Perhaps I'll call it closing user accounts rather than deleting. I also think I'll enforce the uniqueness of the email address higher up. During the actual registration process rather than in the database itself. Though I think that might break indexing.
    – xerotolerant
    Commented Jun 29, 2017 at 19:15
  • Since you still haven't told me what behaviors you want, I can't really say if "closing" is a good word. Not sure what the advantage of managing the email outside of the database would be. You'd have to explain what you have in mind.
    – candied_orange
    Commented Jun 29, 2017 at 19:23
  • I'll edit the question for clarity so it doesn't get buried in the comments.
    – xerotolerant
    Commented Jun 29, 2017 at 19:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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