Question

An issue that has come to light is to open up our application (we can visualise it a bit like an online shop) to unregistered users.

At the moment, there is an admin system where staff are added by superusers and a website with customers who add themselves by registering.

We have been asked to allow customers to use the website without registering or logging in, but we don’t want to break the ‘orders’ table – we still need to refer to each customer individually and maintain the registered users functionality (address lookup, purchase history, etc). The main idea we’ve been mulling over is to use the unregistered customer’s email address as a replacement for the surrogate key (or a hash of it) in the customer table so that new and old customers can just enter their email address at checkout to be added to our database and receive confirmation of their order. The problem of different email addresses per customer can be alleviated by a ‘merge’ tool on the admin side, and the problem of multiple customers sharing the same email (some office environments) isn’t that much of a problem for us.

The main question is this: how do real-world applications handle unregistered users?

Update in response to answers

We don’t want to force registered users to login each time even if their email address is already on our system as a registered user. Also, if people are advocating using the email address as a key, how would you deal with a scenario where a registered account holder gives up their email address to someone else?

Answer 1

In our company, we do it this way:

1. when ANY user makes an order, we look up his email (which he is required to specify and is unique) in customers table.
2. If it isn’t there, we simply create the user (we already have all required data from the user’s order) and we mark him as registred=0.
3. now we continue the order process with his user id.
4. when somebody registers under that email, we simply update his credentials (whatever he specifies), while keeping his order history and whatever else. I don’t think that makes a security concern, the user is required to confirm the email address, so unless the account is really his, he wouldn’t register anyway.

We don’t allow already registred email to create an order, so that should clear out your merging of emails, because nobody will be able to create a registered and unregistered account under one email address and when he’s done, he will never be able to shop unregistered again. Hope this helps.