Уникальные ограничения идентификации пользователя

Question

Я создаю приложение, которое требует, чтобы я однозначно идентифицировал каждого пользователя, чтобы они не могли регистрироваться несколько раз в одной службе. Для этого мне нужно будет искать личные данные пользователя против существующих в базе данных, чтобы увидеть, есть ли дубликаты.

У меня уже есть уникальное ограничение на имя пользователя и адрес электронной почты, однако процедура требует от меня проверки следующих 9 полей, поскольку они проверяются во время процедуры KYC (Know Your Client), поэтому у меня есть «определенность», что они точны.

1. FirstName
2. MiddleName
3. Фамилия
4. DateOfBirth
5. Пол
6. Страна
7. Адрес1
8. Адрес2
9. Address3

Я построил уникальное ограничение индекса (MySQL) для этого процесса, однако, учитывая довольно большое количество полей, я размышлял над тем, может ли быть разумнее просто проверять с серверной стороны и отказаться от уникального индекса в целом.

Принимая во внимание, что эти поля будут запрашиваться только при регистрации, KYC и финансовых транзакциях. Какова наилучшая практика, когда дело доходит до создания уникального индекса в большом количестве полей и какое влияние на производительность он может иметь в системе?

Answer 1

В InnoDB у каждого вторичного ключа первичный ключ неявно добавляется в конец. Следовательно, разумно иметь «маленький» первичный ключ.

Следовательно, было бы лучше иметь AUTO_INCREMENT для PRIMARY KEY и иметь 9-столбцовый UNIQUE (вторичный) ключ. (Это в отличие от 9-столбца PRIMARY KEY.) Разница вступает в игру только в том случае, если есть другие «вторичные ключи».

В качестве альтернативы вы можете иметь составной ключ не UNIQUE на нескольких из этих столбцов и иметь код, чтобы завершить ограничение уникальности.