Лучшие практики по первичному ключу, автоинкременту и UUID в RDBM и базах данных SQL - PullRequest
Новая
       25

Лучшие практики по первичному ключу, автоинкременту и UUID в RDBM и базах данных SQL

0 голосов
/ 20 сентября 2018

Мы разрабатываем таблицу для пользовательского объекта.Единственным нетривиальным требованием является постоянный URL-адрес объекта пользователя (например, его профиль).В интернете много о int / long и UUID.Но мне все еще неясно.

  1. Учитывая тот факт, что профиль содержит личную информацию, не рекомендуется вставлять в URL предсказуемый идентификатор.Я прав?
  2. Для удовлетворения первого я могу иметь первичный ключ в качестве UUID и встраивать его в URL.Но есть два вопроса.Должен ли я в любом случае беспокоиться о снижении производительности из-за использования UUID в качестве первичного ключа;индексирование, вставка, выбор, объединение?

Сказав, что одно из следующего лучше (относительно вышеупомянутого)?

CREATE TABLE users(
  pk UUID NOT NULL,
  .....
  PRIMARY KEY(pk)
);

или 

CREATE TABLE users(
  pk INT NOT NULL AUTO_INCREMENT,
  id UUID NOT NULL,
  .....
  PRIMARY KEY(pk),
  UNIQUE(id)
);

Ответы [ 3 ]

0 голосов
/ 20 сентября 2018

Этот вопрос основан на мнениях, так что вот мой.

Мой вариант - использовать второй, отдельный UUID от PK.Дело в том, что:

  • PK уникален и не доступен для общественности.
  • UUID уникален и может быть доступен общественности.

Если по какой-либо причине UUID скомпрометирован, вам нужно его изменить.Замена PK может быть дорогой и имеет много побочных эффектов.Если UUID отделен от PK, то его изменение (хотя и не тривиальное) имеет гораздо меньшие последствия.

0 голосов
/ 20 сентября 2018

Не делайте это вашей базой данных первичным ключом: это вызовет проблемы в будущем, если вы захотите изменить свою технологию базы данных.И если вы увеличите число, ваши конкуренты будут знать, сколько у вас пользователей и как быстро вы добавляете новых.

0 голосов
/ 20 сентября 2018

Это вопрос выбора на самом деле, и этот вопрос может вызвать основанные на мнении ответы с моей точки зрения.Что я всегда делаю, даже если это избыточно, я создаю первичный ключ в столбце автоинкремента (я называю это техническим ключом), чтобы он оставался согласованным в базе данных, позволяя изменить «первичный ключ» в случае, если что-то пошло не так на этапе проектирования, итакже позволяет сэкономить меньше места в случае, если на ключ указывается ограничением внешнего ключа в любой другой таблице, а также я делаю ключ-кандидат уникальным, а не нулевым.

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

В этом случаеЯ бы пошел на ваш второй вариант, но слегка измененный: 

CREATE TABLE users(
  pk INT NOT NULL AUTO_INCREMENT,
  id UUID NOT NULL,
  .....
  PRIMARY KEY(pk),
  UNIQUE(id)
);
...