Добрый день.
Ситуация следующая. Есть высоконагруженная БД (очень много пользователей, правда объем файла базы всего 60 гигов).
Основная логика работы крутится вокруг одной таблицы. Это приходится принимать как данность.

Схематично таблица выглядит так:
- ID - код записи, формируемый генератором
- ORD_ID - код организации
- PERFORMER_ID - код исполнителя
- DONE_DATE - дата исполнения
- DONE_TIME - время исполнения
- ну и далее поля данных

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

Поставлена задача
- Сделать нумерацию задач локально для каждого исполнителя.
- Каждый день для каждого исполнителя нумерация задач должна начинаться с единицы.
- При добавлении новой задачи она получает очередной порядковый номер для этого исполнителя в этот день (ну т.е. max(num) + 1)


Может кто подкинуть идею, как это правильнее организовать, чтобы минимизировать тормоза и исключить возможные ошибки в нумерации?
Предложение "сказать что это неправильно и не делать" не подходит. Задача поставлена и ее нужно решать.

Мимопроходящий,

авторделай на клиенте, при отображении.
хранить такую хрень нет необходимости.

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

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

Так что интересует меня именно нумерация записей в самой БД и хранение записей в самой БД, о чем я изначально и спросил.

kdv,

а что мне делать когда два клиента "одновременно" добавляют записи в одно расписание?
max(N)+1 сделает ведь один и тот же номер для двух разных записей.



В первой транзакции



Во второй транзакции



Коммичу обе транзакции.
Получаю в таблице

hvlad,

Да. Я думаю в эту сторону. Создать "свой генератор".
Работу с такой таблицей мне придется делать в транзакции?

Вернее параметр NO_REC_VERSION. Ошибся в предыдущем ответе Владу.

hvladimkot,

см выше - либо rc+no_rec_ver, либо snapshot.

Кроме того, я бы использовал



Значит все же так. Думаю что я получил ответ на свой вопрос.

Спасибо всем за советы.

PS: Такой подход у меня уже используется, но на менее востребованной таблице.

Dimitry Sibiryakovimkotа что мне делать когда два клиента "одновременно" добавляют записи в одно расписание?

Для начала - ничего. Собери статистику как часто это происходит и происходит ли вообще.


К сожалению происходит. И чаще чем хотелось бы :(

Ладно, можно закрыть тему.

Мимопроходящийв таком виде не решена задача вставки номера "между существующими"

Я наверное неверно выразился.

Есть задачи
09:00 - №1
10:00 - №2
11:00 - №3

Если мы добавляем задачу на 09:30, то она будет №4. Номер не должны двигаться.
А если удаляем задачу на 10:00, то будет "дырка" в нумерации.

Т.е. нужно решение со своим генератором.
Изначально в задаче про генератор умолчал намеренно, чтобы услышать возможные решения.
Вдруг есть что-то очень простое и эффективнное.

Но раз меня все начали тыкать носом в обновление с блокировкой, значит ничего лучшего нет.

PS. Есть много чего, что надо бы сделать в БД и инфраструктуре в целом, но к сожалению приходится заниматься вот такими вот задачами :(

Гаджимурадов Рустамimkot> А если удаляем задачу на 10:00, то будет "дырка" в нумерации.

Что потом вы с этой дыркой делать собираетесь (гусары, молчать!) ?
Присвоить её номер другой записи (событию) ?


Нет, так и останется дыра на этом месте.
Тут уж я не властен что-то менять. За что купил, за то и продаю.
Это не самое интересное требование. Бывает все намного веселее. Бюджетная сфера она такая...

kdvimkotа что мне делать когда два клиента "одновременно" добавляют записи в одно расписание?
ну что за фигня, честное слово. Два клиента, два исполнителя, и прочее, НЕ МОГУТ добавлять задания в расписания одному и тому же человеку.
Таблица ID_человека и номер_задания - номер задания можно делать сколь угодно последовательным для одного ID_человека, никаких проблем.

imkotТ.е. нужно решение со своим генератором.
да нафиг. N людей, а генератор один? N генераторов?
Либо вы задачу неправильно описали, либо вы вместо простого решения начинаете что-то сложное выдумывать.

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

Не расстраивайтесь так, вы тут немного развлекетесь и поржете, а мне с этим еще и жить надо будет

Мимопроходящий26.10.2017 15:10, imkot пишет:
> Бюджетная сфера она такая...

она "такая" из-за восприятия любого бреда заказчика как "единственно возможное решение".


Вот именно из-за таких ответов я и не люблю задавать вопросы на форуме. Предпочитаю просто читать и искать решения.
Вроде бы я в самом начале сказал что задача не подлежит изменению. Есть ТЗ и его надо решать, либо его решит кто-то другой. Но чтобы поддерживать и развивать свою систему приходится решать и такие вот задачи в угоду заказчика, который не сам принял его решение, а его спустили вышестоящие органы.

Впрочем это получается полный оффтоп. А сегодня еще не пятница. Хотя и четверг уже к концу у меня подходит.

Старый плюшевый мишкаА на каком по счёту генераторе нонче база ломается? Вмешиваться в проктологический консилиум намерения не имею, любопытно просто, остал от жизни-то.

В том то и беда, что это не будет генератор БД. Это будет таблица счетчиков, для эмуляции работы генератора.
"генератор" надо было писать в кавычках.

Влад вполне исчерпывающий ответ дал вот тут 20902280 . Такое решение в БД уже есть, но для таблицы которая не так часто модифицируется.