Генератор случайных идентификаторов, сопоставление с тем же столбцом

Question

Есть несколько организаций, которым мы хотим скрыть свой точный идентификатор от клиентов - основная причина в том, что мы не хотим, чтобы клиенты знали, сколько их в БД.

например. из URL http://mydomain/user/get/27, говорится, что это 27-й пользователь.

Поэтому я реализую решение, которое назначает случайный идентификатор (который должен быть уникальным). Другими словами, вместо использования уникального порядкового номера, я собираюсь использовать уникальное решение непоследовательности + случайное число.

например. из URL, http://mydomain/user/get/8534023,, который на самом деле является 27-м пользователем.

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

, например

CREATE TABLE IF NOT EXISTS `test` (
  `id` int(10) unsigned NOT NULL AUTO_INCREMENT,
  `somethingElse` varchar(255) NOT NULL,
  PRIMARY KEY (`id`)
)

CREATE TABLE IF NOT EXISTS `map` (
  `id` int(10) unsigned NOT NULL,
  /* Foreign Key to test table */
  `parent` int(11) NOT NULL,
  PRIMARY KEY (`id`),
  KEY `parent` (`parent`)
)

VS.

CREATE TABLE IF NOT EXISTS `test` (
  /* Assign random ID here */
  `id` int(10) unsigned NOT NULL,
  `somethingElse` varchar(255) NOT NULL
  PRIMARY KEY (`id`)
)

Для меня последнее удобнее, так как мне не нужно поддерживать карту или настраивать DAO / приложение для использования сопоставленного идентификатора (или внутреннего идентификатора). В обоих случаях мне нужно написать собственный генератор случайных идентификаторов.

Answer 1

Вы правы - последний - лучший подход. Это отношение один-к-одному - нет причин иметь отдельную таблицу. Я рекомендую иметь:

• индекс "фальшивого" user_id, так как он будет использоваться для поиска
• УНИКАЛЬНОЕ ограничение на столбец, чтобы гарантировать, что повторяющиеся значения не вставляются

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

Answer 2

Почему бы вам просто не установить начальное значение начального приращения на что-то вроде 8534023? Ваш первый клиент - 8534023, второй - 8534024 и т. Д. Ваши клиенты никогда не узнают, что это значит, но вы узнаете.