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

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

пользовательская таблица имеет следующее определение

CREATE  TABLE IF NOT EXISTS `mydb`.`user` (
  `id` INT NOT NULL,
  `username` VARCHAR(25) NOT NULL,
  `email` VARCHAR(25) NOT NULL,
  `external_customer_id` INT NOT NULL,
  `subscription_end_date` DATETIME NULL,
  `column_1` VARCHAR(45) NULL,
  `column_2` VARCHAR(45) NULL,
  `colum_3` VARCHAR(45) NULL,
  PRIMARY KEY (`id`),
  UNIQUE INDEX `username_UNIQUE` (`username` ASC),
  UNIQUE INDEX `email_UNIQUE` (`email` ASC),
  UNIQUE INDEX `customer_id_UNIQUE` (`external_customer_id` ASC) )
ENGINE = InnoDB

Я столкнулся со следующими проблемами со столбцами-кандидатами первичного ключа:

Столбец идентификатора

Плюсы

• Нет смысла для бизнеса (стабильный первичный ключ)
• более быстрое соединение таблиц
• более компактный индекс

минусы

• не "естественный" ключ
• Все таблицы атрибутов(s)должны быть объединены с "главной" пользовательской таблицей, поэтому не-объединяющие прямые запросы невозможно
• вызывает менее «естественные» SQL-запросы
• Утечки информации:пользователь может определить количество зарегистрированных пользователей, если начальное значение равно 0 (изменив начальное значение, упорядочите это)ii)Пользователь, зарегистрировавший профиль как пользователь_A в момент времени_X и некоторое время спустя как пользователь_B в момент времени_Y, сможет легко подсчитать количество зарегистрированных пользователей за период времени ((Идентификатор пользователя_B)-(Идентификатор пользователя_A)/(время_Y -время_X))

столбец электронной почты

Плюсы

• Нет

Минусы

• пользователь должен иметь возможность изменить адрес электронной почты. Не подходит для первичного ключа

столбец имени пользователя

Плюсы

• «естественный» первичный ключ
• Меньше соединений таблиц
• более простые и «естественные» запросы

Минусы

• столбец varchar работает медленнее при объединении таблиц
• индекс столбца varchar менее компактен, чем индекс столбца int
• очень сложно изменить имя пользователя, поскольку внешние ключи зависят от значения.Решение:«Синхронизация» всех внешних ключей в приложении или , не позволяющая пользователю изменять имя пользователя, например. пользователь должен удалить профиль зарегистрироваться новый

внешний_столбец клиента

плюсы

• может использоваться в качестве внешней ссылки для клиента и не содержит информации (возможно, не-редактируемое имя пользователя может вместо этого использовать?)

  минусы

• возможна утечка информации, если она является автоматически инкрементной (если возможно)

• проблематично генерировать значение unqiue, если автоинкрементный суррогатный идентификатор уже используется, поскольку механизм MySQL innodb не выполняет многократное авто_инкрементирование столбцы в одной таблице

какова обычная практика при выборе первичных ключей пользовательской таблицы для масштабируемое веб-приложение электронной коммерции? приветствуются все отзывы