Идея Латука интересна, но кажется не вполне прозрачна:

Положим: 1)таблица клиентов. 2)Таблица очередей (не апдейтится).
3) Таблица "проводок" (сдвигов, с полями дат проводок).

Для простоты возьмем 1 очередь. пример вырождается в таблицу клиентов (ik) с полем номере очереди N0, и таблицу шифтов с полями даты, клиента и величины сдвига (шифта shift). В 0 приближении новый номер клиента IK на дату DATE будет считаться как
N=N0(IK) + Sum(shift(IK, date<DATE)) + f(ik<>IK)
где физ смысл f(ik<>IK) - это сдвиг в очереди клиента IK из-за сдвигов других клиентов (ik<>IK). Если не учитывать этого момента, то будут совпадения в величинах N0(IK) + Sum(shift(IK, date<DATE)) для разных IK. Видит ли латук, как в SQL правильно посчитать шифт элемента из за сдвигов других?

если я предположу, что от порядка шифтов на некий момент времени результат не изменится, я, кажется, могу записать:
f ~ COUNT(ik, WHERE N0(ik)<N0(IK) AND (N0(ik)+ Sum(shift(ik<>IK,date<DATE))>N0(IK))
- COUNT(ik, WHERE N0(ik)>N0(IK) AND (N0(ik)+ Sum(shift(ik<>IK,date<DATE))<N0(IK))
- а это вполне переводится на SQL, правда скорость его будет похоже расти как произведение числа клиентов на полное число проводок в очереди. (и, честно сказать, я не до конца уверен в логичности перехода от перестановочности шифтов к приведенной записи функции сдвига номера текущего клиента сдвигами других).

С другой стороны, если в таблице проводок все же при атомарной операции записывать не величину изменения "сдвига" для одного клиента, но величины всех сдвигов (тем не менее сохранив дату операции - для истории), то при увеличении числа записей в >~2 раза <~NO раз (2 - для перестановок только последовательных, а NO (где - NO длина очереди) - для перестановок из начала в конец очереди), мы сможем считать номер как
N=N0(IK) + Sum(shift(IK, date<DATE))
(т.к. сдвиг других элементов уже учтен в параллельных проводках сдвига других клиентов той же операцией), и сэкономить на посчете внутренних сумм в вычислении сдвига другими клиентами.

При этом:
1. все записи проводок только добавляются, блокировки (если есть позаписная) одним процессом другого быть не должно
2. таблицу "проводок" разумно разбить на 2 а)- "шапка" - таблица операций с полем даты и расшифровкой операции, б) - атомарные проводки-шифты элементов (согласованные проводки можно делать как в триггере, так и в приложении, в одной транзакции).

AbelЗ.Ы. Кстати, а смысл добавлять кучу шифтов, когда можно добавить на текущую дату просто пересчитанные номера очереди. И никаких count, sum etc. Просто "=" и усе!!! И история хранится, и устаревшую историю можно скидывать периодически в архив. Гениально. Вот что значит симбиоз идей
Согласен.

Более того, "проводки" при помощи одиночных записей "шифтов" плохи тем, что на самом деле высказанная выше гипотеза перестановочности сдвигов не имеет никаих прав на существование. (Что демонстрируется при помощи двух "сдвигов": - 2-го элемента через один и третьего через один - а именно, в зависимости от порядка мы будем в результате иметь либо 1-2-3-4 (если сначала сдвинуть второй, потом тертий) или 1-4-2-3 - если сначала сдвигать третий, потом второй)) Т.е. при помощи обычных групповых операций SQL итогового положения по истории "нессимметричной" записи проводок (только для одного элемента, а не всех согласованных сдвигов номеров очереди) не восстановить - нужно еще и учитывать порядок "проводок" - процедура становится существенно рекурсивной. Посему придется записывать все произошедшие сдвиги (именно это выше и предлагалось - "шапка" - идентификатор и аналитика операций, сдвиги - величины смещений нумерации всех сдвинутых операцией элементов). Что эквивалентно записи "снимка" очереди (достаточно перезаписать не всю очередь, а только сместившиеся при сдвиге элементы - записей в таблице истории будет существенно меньше, но с выборкой придется исхитрятся - на вскидку не так уж сложно - для каждого клиента надо выбирать последнюю по времени, не превосходящему момент выборки, запись в очереди, "моментальный снимок" будет запросом наподобие:
SELECT ik, (SELECT TOP 1 nk From очередь WHERE очередь.ik = клиенты.ik AND очередь.Дата<=[Дата выборки] AND очередь.id=[очередь выборки] ORDER by очередь.Дата DESC) AS nk FROM клиенты)
- тут надо смотреть, что вы предпочитаете оптимизировать, быстродействие на выбоку или объем и быстродействие на запись.


Вероятный плюс записей полного снимка очереди: - можно наложить констрайнт типа уникального индекса (id,ДАТА,ik,nk), который будет гарантировать логическую непротиворечивость снимков как целое. При записи в историю только сместившихся в очереди клиентов такой контроль логической непротиворечивости за счет констрайнтов в мдб точно не возможен (придется в вба проверzть отсутствие совпадений nk в вышеприведенной выборке), а на SQL-сервере скорей всего потребует аналогичного (вба) триггера (на стейтмент, а не на запись) проверки непротиворечивости.



ЗЫ. под триггерами в мдб я ничего не подразумеваю. я подразумеваю, что ваш мдб(адп,мде) может быть клиентом чего угодно, в т.ч. некоего "нечта", поддерживающего такие небезызвестные механизмы "обработки событий" данных, как тригеры на стейтмент. Если это так - уместнее использовать триггеры, чем ненадежный (не перекрывающий все возможные способы изменения данных) механизм обработки событий форм клиента.