Альтернативы столбцу идентификации для таблицы с частыми вставками и удалениями? - PullRequest
Новая
       20

Альтернативы столбцу идентификации для таблицы с частыми вставками и удалениями?

1 голос
/ 08 марта 2012

Допустим, у меня есть такой сеанс: 

[Session]
-------
Id: int
UserId: int

Представьте себе, что он используется на сайте с очень высоким трафиком, а Sessions очень часто добавляются и удаляются. Если бы я сделал столбец Id каждой таблицы столбцом Identity, как бы я мог легко поддерживать заполнение идентификаторов, чтобы они не выходили за пределы типа данных int? Есть ли альтернативный способ обеспечения уникального идентификатора, о котором я не думаю? Заранее спасибо.

Ответы [ 4 ]

3 голосов
/ 08 марта 2012

вместо int сделать его bigint, это будет увеличиваться до 9,223,372,036,854,775,807

Вы также можете, конечно, начать с -9,223,372,036,854,775,808

см. Также Что делать, когда ваш столбец идентичности исчерпан

1 голос
/ 08 марта 2012

Если у вас есть период обслуживания сайта, вы можете просто повторно заполнить столбец идентификации. Наф, но просто.

1 голос
/ 08 марта 2012

Сделайте id гидом вместо int.Вы получаете уникальные идентификаторы сессий, которые невозможно угадать и которые легко реализовать с помощью Guid.NewGuid ().

0 голосов
/ 08 марта 2012

Как долго может существовать данный сеанс?Если ни один сеанс не будет длиться более X периода времени, и вы знаете, что в любой момент времени в таблице никогда не будет более N сеансов, и вы знаете максимальную скорость, с которой будут добавляться новые сеансы, тогда вы могли быреализовать некую форму системы циклических очередей с циклическим переключением по максимальному набору чисел.

Например, если в любой заданный момент времени в таблице никогда не будет более 1000 строк, будет не более 1000 строк.добавляется в любой заданный 5-минутный период, и ни одна строка не будет сохраняться более 2 дней (ночная процедура очистки?), тогда вы будете проходить через 1000 * 2 * 24 * 12 = 576 000 идентификаторов каждые два дня ... где каждыйИдентификатор добавляется, используется и удаляется из системы каждые два дня.Постройте круговую логику очереди вокруг большого коэффициента безопасности этого числа (возможно, 5 000 000), и вы можете быть покрыты.

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

--  Create table
CREATE TABLE NextId
 (NextId  int  not null)

--  Add the one row to the table
INSERT Nextid (Nextid) values (1)

При желании, здесь можно включить триггер INSERT / DELETE, чтобы предотвратить добавление или удалениестрок

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

CREATE PROCEDURE GetNextId

    @NextId  int  OUTPUT

AS

    SET NOCOUNT on

    UPDATE NextId
     set
        @NextId = NextId
      ,NextId = (NextId + 1) % 10 -- 5000000

    RETURN

Вот как будет вызываться процедура: 

DECLARE @NextId  int

EXECUTE GetNextId @NextId output

PRINT @NextId

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

...