Question

Our application has an online shop among other features, and users are normally requested to register before completing a sale, creating a unique customer_ID in the process. When they return, they can log in and their contact details and transaction history are retrieved from the database.

We are now exploring what to do in the case of an ‘anonymous’ or ‘guest’ customer, opening up the online shop to customers who don’t want to register, and also for sales logged in the backend application, where taking the customer’s email, postal address, etc is just too time consuming. The solution has applications outside the online shop too.

Multiple companies use the same database, and the database is built on a party model structure, so we have explored a few options:

1. Store all anonymous customers under one pre-defined customer_ID in the transaction table:
   1. customer_ID = 0 for every anonymous user, and customer_ID > 0 for every real user
      • This is straight-forward to hard-code into the application
      • But more involved to determine which customers belong to which company
      • Should details for customer_ID = 0 exist in the customer table in the database or as an object in the application?
        • If in the database, what database-level constraints can be made to ensure that it always exists?
        • If not in the database, then foreign key constraints from transaction.customer_ID to customer.customer_ID no longer work
   2. customer_ID is the same as the company party_ID
      • Easier to determine aggregate sales for each company, etc
      • This would confuse matters as it would appear that the company is its own customer, rather than other unique customers
2. Generate a unique customer_ID for every new anonymous customer (per session)
   • What if the same physical user returns? There will be many records repeating the same sort of data; email, shipping address, etc.
3. Use another unique key, such as email address, to refer to a customer
   • Not always reliable as people sometimes use more than one email address, or leave old addresses behind.
   • What if there is no email address to be taken, as is the case on the shop floor, pro forma invoices, etc?
4. Some other Stack Overflow inspired solution!

Addition

A combination of #2 and #3 has been suggested elsewhere – attempt to store a single record for each customer, using the email address if possible, or a new record on every visit if not.

I should point out that we don’t need to store a record for every anonymous customer, but it just seems that the relational database was built to deal with relationships, so having a NULL or a customer_ID in the transaction table that doesn’t reference an actual customer record just seems wrong…

I must also stress that the purpose of this question is to determine what real-world solutions there are to recording ‘casual’ transactions where no postal address or email address are given (imagine a supermarket chekout) alongside online shop transactions where an email address and postal address are given whether they are stored or not.

What solutions have the SO community used in the past?

Answer 1

Assuming you require an e-mail address for all online orders, you could create a temporary account for every customer at the completion of each order when they are not logged in.

This can be done by using the shipping address and other information provided during checkout to fill in the account, and e-mailing a random temporary password to them (optionally flagging it to require changing on the first log-in, if that functionality is built into the website). This requires minimal effort on their part to setup the account, and allows them to sign in to check their order status.

Since the primary key in your database is the customer_id, it should not cause conflicts if they continue making new accounts with the same e-mail/address/etc, unless you have code in place to prevent duplicates already. It’s rare for someone to create more than one temporary account though, since it’s easier to log in with the password e-mailed to them than entering their data again.

For the backend orders, we generally create an account in the same way as above for every customer. However, if they don’t have an e-mail address (or they only want to purchase by phone), we generate an account with their shipping information and a blank e-mail address (have to code an exception to not send temporary passwords/order confirmations when it’s blank). The customer_id is given to them, and their shipping information and company name are stored in the account to look up and expedite future orders.