Несколько уникальных счетчиков в таблице - PullRequest
0 голосов
/ 16 февраля 2010

У меня проблема с тем, что мне нужно сохранить и увеличить поле номера объекта в таблице, однако это число должно быть уникальным в пределах данного логического домена, а не по всей таблице.

Примером может быть несколько предприятий, планирующих несколько рабочих мест; Job.Number должен быть уникальным в рамках бизнеса.

Поэтому мне нужно убедиться, что одновременные операции по созданию рабочих мест не производят задания с одинаковым номером.

В настоящее время я вижу только один способ реализовать это (в postresql):

Заблокируйте таблицу с помощью самоблокирующегося типа блокировки, скажем «SHARE UPDATE EXCLUSIVE», чтобы все другие операции этого типа приходились в очередь и ожидали, гарантируя, что функция MAX () всегда возвращает уникальное значение.

Однако, похоже, у этого решения есть огромный недостаток - оно, по сути, создает узкое место для всех операций INSERT в таблице Jobs.

Я не думаю, что могу использовать последовательности Postgreql, потому что:

  1. Я не хочу создавать новую последовательность для каждого нового бизнеса
  2. Может иметь пробелы

Не могли бы вы предложить другие способы решения этой проблемы?

Ответы [ 2 ]

1 голос
/ 16 февраля 2010

Прежде всего, если все, что вам нужно, это отдельное число, почему бы вам не использовать последовательность для его генерации?

Если с общей последовательностью не все в порядке, так как это приведет к появлению «пробелов» (т. Е. Задания № 1 для бизнеса могут быть пронумерованы как 1,2,5,6,23, а задания № 2 для бизнеса могут получить 4,7,8,20 и и так далее) или по какой-либо причине, почему бы вам не создать таблицу «счетчиков заданий»:

> Business ID | Job Counter 
----------------------------
> Business #1 | 23 
> Business #2 |  3 
> Business #3 | 11
> Business #4 | 76

Таким образом, когда вам нужно сгенерировать следующее задание для бизнеса №2, вам нужно заблокировать только строку №2, увеличить ее и продолжить. Предполагая, что Postgres может блокироваться на уровне записи, вы могли бы сделать это более масштабируемым.

0 голосов
/ 17 февраля 2010

А как насчет SELECT * FOR UPDATE оператора?

Также хочу заметить, что CREATE SEQUENCE имеет опцию «CACHE», поэтому она может работать быстрее, если вы беспокоитесь о некоторых пробелах.

...