Существуют ли другие стратегии для автоматического увеличения первичного ключа, кроме значения по умолчанию x + 1?

Question

Существуют ли другие стратегии для автоматического увеличения первичного ключа? Таким образом, вместо обычного x + n, где n равно 1, может ли n быть другим числом, таким как 5? Или, может быть, случайное число, но такое, что следующий идентификатор все еще уникален?

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

Answer 1

В T-SQL (MS SQL Server) используется свойство IDENTITY :

" ИДЕНТИЧНОСТЬ [( семя, приращение )]

seed Это значение, которое используется для самой первой строки, загруженной в таблицу.

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

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

Редактировать: почему вы должны быть осторожны:

Вот некоторые псевдо-SQL, которые показывают опасность использования вашего собственного приращения и т. Д .:

1. @NextID = SELECT MAX(ID) FROM MyTable;

2. INSERT INTO MyTable(ID + 1, Name) VALUES (@NextID, "Dan");

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

Чтобы обойти это, нужно иметь LOCK до шага 1 и освобождать его после шага 2. Это эффективно ставит в очередь все транзакции, и база данных работает в режиме «одного пользователя». В системах с большим объемом это может быть очень вредно для производительности.

Вот почему все основные базы данных имеют последовательности или встроенные методы для автоинкрементных первичных ключей.

Answer 2

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

Answer 3

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

Ключи хранятся отдельно, определяя смещение и приращение для каждого сервера. Например,

auto_increment_increment= 2
auto_increment_offset   = 2

Answer 4

Для случайных идентификаторов (и тех, которые вы можете сделать уникальными для разных серверов), вы можете использовать поля GUID вместо полей int. У них есть свои проблемы и проблемы, и вы должны прочитать о них подробно, прежде чем приступить к такой конструкции.

Answer 5

Зависит от используемой вами СУБД. В oracle это было бы так (при условии, что вы установили триггер для первичного ключа):

SQL> create sequence fun_seq
     start with 8
     increment by 2;