Database Design – Unique Identifier for Customer and Payment Details in Tourism Company

database-designunique-constraintuniqueidentifier

Given a tourism company, Air T&T, has customers. When a customer checks in to an AirTnT facility (i.e. house-share), AirTnT records the customer's first and last names, address, date of birth, current mobile number, one unique identifier for identity verification, one unique identifier for payment details, and emergency contact number.

I was thinking social security number for identity verification and bank account number for payment details? What are the pros and cons of each-especially for payment details? I know credit card number is bad because of the security threats?

Best Answer

Your question is a business one, not a database one. The 'unique identifier', or your key, should be the key that the business uses to distinguish customers. Some may use a user-name, others may use Email, some may use SSN, some may use retina scan. The database schema is a MODEL of the business reality, therefore, it should follow the keys that are used in the real world.

It won't help you much to assign a surrogate key, like IDENTITY or GUID, as you still won't be able to distinguish one customer from another, as you can't extract that property from the customer itself, and name is typically not enough. What would you do if a customer walks into the office and there are 4 other customers with the same name?

Let's say you have 2 customers named John Doe. You insert them into the table and assign them surrogate primary keys with ID 34 for one, and 237 the other. A customer walks into the store. Says 'hi, I'm John Doe and I'm here to buy an item'. You type 'John Doe', and into the screen to pull up his account, and you see 2 options - John Doe 34, and John Doe 237. You look at the customer and ask "Are you John Doe 34 or 237?". The customer thinks you're crazy and walks away... The ID doesn't identify the ENTITY, it is a relic of thought from 50 years ago when magnetic tapes had address pointers...

The question mentions that the data collected is "customer's first and last names, address, date of birth, current mobile number". If that is all you have to distinguish customers in the 'real world', that is your key. Perhaps it is just first and last name, perhaps first and last name + address, perhaps just mobile number...

As for payment, again, the question does not provide enough information for you to give an answer. What payment methods are available? Cash? Checks? Credit Cards? Wire Transfers only? Can the customer pay in multiple payments and multiple payment methods? Again - whatever the BUSINESS uses to distinguish payments, is what your key will be.

HTH