-2-,

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

[quot Elic]SkilledJuniorТы не слышал про автономные транзакции?
Не слышал чтобы они позволяли изменять один и тот же ресурс одновременно двумя сеансами, все равно обработка становится последовательной, а в данном случае транзакции и так короткие.

Staxя б заводил табличку с дата,...,номер и в автономке палил (выдавал) номера
в нас реально работает очередь, таланчики выдает автоматы(киоски) и возможно менеджер "очереди"
главная задача чтоб было меньше скандалов, почему я жду, а соседа обслужили
stax
Тогда уж лучше по классике, создаем табличку ресурсов, создаем табличку ресурс-дата-номер, для выдачи номера выполняем select ... for update ресурса из таблички ресурсов, запрашиваем для этого ресурса текущий номер, если номер на дату есть то +1 и update, если нет то номер равен 1 и insert.

-2-SkilledJuniorпо классикеВо-первых, селект тут ни на что не влияет, кроме увеличении времени транзакции. Во-вторых, не защищает от дублей. Фактически, это вариант изложенный автором, отягощенный вспомогательным "ресурсом".
for update влияет.

Гарантию отсутствия дублей даст ограничение в виде уникального индекса, я думал что наличие соответствующих ограничений целостности на таблицах само собой разумеется, ошибся ...

Если классический алгоритм для вас "отягощен", то это ваш выбор,

-2-SkilledJuniorfor update влияетВозможно я не правильно понял изложение. Алгоритм предполагает две вспомогательные таблицы для эмуляции lock table in exclusive mode целевой таблицы?
Да, можно пойти в лоб, заблокировать всю целевую таблицу и найти в ней талончик с максимальным номером на текущую дату, после чего вставить новую запись.

Elic streletsПока решил проблему через поле с текущим номером коробки в таблице товаров.В данном случае самое правильное решение. Если получать следующий номер при помощи:
, то ни конфликтов, ни дырок не будет. Будет лишь конкуренция в пределах одного товара, которая при грамотном кодировании сводится до незначительных задержек. К тому же на практике такая конкуренция может быть редкой.
Естественно, это будет медленнее последовательностей - се ля ви.
Так я это и сделал, только товар в моем случае это комбинация ресурса и даты, и эта комбинация может отсутствовать, т.е. нужен не просто update, а upsert.

Создаете таблицу с семафорами eq_resources с полем res_name, в таблицу вставляется одна запись со значением TURN, создаете вторую таблицу eq_numbers с полями res_name, d_act, nm_turn, на нее вешаем внешний ключ на eq_resources поле res_name и ограничение уникальности по полям res_name, d_act. Таким образом последний выданный на определенный день номер будет храниться в поле nm_turn.

Далее пишите хранимую процедуру выдачи номера, чтобы долго не держать семафор занятым процедура должна выполняться как автономная транзакция:
1. Захватываем семафор select ... from eq_resources where res_name = 'TURN' FOR UPDATE
2. Находим последний выданный номер в таблице eq_numbers
3. Если номер найден то номер+1 и update таблицы eq_numbers, если не найден то номер равен 1 и insert в eq_numbers
4. Возвращаем в вызывающую программу новый выданный номер.

В вызывающей программе сначала получаем новый номер, потом выполняется insert из первого поста темы подставляя в него полученный номер.