I’m designing a database that will be the backend for a marketplace website. There will be buyers and sellers creating accounts. I am planning on having a single sign in form for all types of account and a central accounts table that will hold account details common to all types of account, where user credentials will be stored and can be checked against when any user signs in.
The user credentials will consist of Email and Password. The Email column of the table will be a unique column so an email address can only corrospond to a single account.
But the problem appears when a user wants to delete their account. A user will be able to terminate their account but much of the data related to their account shall be retained in the database. It shall be necessary to retain the data as it will be relevant to other users and the site in general. For example messages, orders, disputes etc. As data has to be kept for buyers to see details about sellers in their past order, really all account data has to be kept and just given a status of terminated.
So what happens if once a user has terminated their account but they try to create a new account with the same email address? They wouldn’t be allowed to because there is already an account with that email address and a terminated status.
My first idea was to replace the email address with a null when an account is terminated. So the email could be used again for a new account, but then I realised a unique column can only have one NULL value.
My next idea was to transfer termiated accounts to another table and remove the email column. However this doesn’t make sense as many other tables in the database will have foreign keys that reference the original table.
Another Idea is to have three core account tables.
AccountInventory: AccountID_PK, Status
ActiveAccounts: AccountID_PK, Email, Password, PasswordSalt, AccType, AccStatus
TerminatedAccounts: AccountID_PK, AccType
This way I could reference the AccountInventory table with foreign keys in my other tables. Use the ActiveAccounts table to check credentials as users sign in. And move deleted accounts to the TerminatedAccounts table whilst still maintaining referential integrity of other data to that account as foreign keys reference AccountInventory.
Is this the best way to achive this functionality of enabling users to reuse an email address whilst maintaing the integrity of the data? It seems a little awkward to me having an AccountInventory table that essentially holds nothing other than Account IDs that all other tables that need to JOIN with ActiveAccounts or Terminated Accounts will have to JOIN though.
So is this the best solution or is there a smarter way of doing this?
Kind Regards,
Duncan
What about a User table with an unique key based on email AND status?
You still can have referential integrity but poses a problem when that user wants to cancel second account. In this case, you could to merge those two accounts, as refers to same user.
If that merge isn’t possible, you could also to create a date range where that account is valid and making it part of your unique index, and enforce there’s only an email address valid at time using triggers or something similar.