Unique User Identification Constraints

Question

I am building an application that requires me to uniquely identify each user, so that they may not register multiple times on the same service. To do this I will need to search the user's personal details against existing ones in the Database to see if there are duplicates.

I already have a unique constrain on the username and email address, however, the procedure requires me to check the following 9 fields as they are vetted during a KYC (Know Your Client) procedure, so I have the 'certainty' that they are accurate.

1. FirstName
2. MiddleName
3. Surname
4. DateOfBirth
5. Sex
6. Country
7. Address1
8. Address2
9. Address3

I was building a unique index constraint (MySQL) for this process, however, given the rather large number of fields I was pondering whether it may be wiser to simply to the checking from the server side, and forgo the unique index altogether.

Keeping in minds that these fields will be queried only during registration, KYC, and financial transactions. What is the best practice when it comes to doing a unique index on a large number of fields, and what performance impact is it likely to have on the system ?

Answer 1

In InnoDB, each secondary key has the primary key implicitly added onto the end. Hence it is wise to have a "small" primary key.

Hence, it would be better to have an AUTO_INCREMENT for the PRIMARY KEY and have a 9-column UNIQUE (secondary) key. (This is as opposed to having a 9-column PRIMARY KEY .) The difference comes into play only if there are other "secondary keys".

Alternatively, you could have a non- UNIQUE composite key on a few of those columns and have code to finish off the uniqueness constraint.