ТаблоидТаблица BalanceTable, обновляемая триггером TurnoverTable.OnAfterDelete, при интенсивном вводе данных становится узким местом. На её строках будут постоянно возникать конфликты обновления со стороны разных сеансов.Странно, что такая простая операция становится узким местом.

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

Тут всё просто - блокируете TurnoverTable и считаете, и никаких отрицательных остатков.

Только блокировка получится больше, чем для расчёта баланса.

ТаблоидalexeyvgСтранно, что такая простая операция становится узким местом.Операция-то простая (вставка в документ энного количества), да делают её десятки человек сразу. И если востребовано одно и то же изделие, неизбежно возникнут драки за ресурс.Ну не знаю... Операция не должна занимать больше милисекунды, значит, до 1000 запросов на ядро. Если пользователи редактирует документы по минуте, то это операция не доставит проблем 240 000 одновременно работающим пользователям для 4-х ядерного проца.

В противном случае у вас неоптимальный код :-)

Я немного утрирую, конечно, но реально вставка/обновление записи ничто по сравнению с другими операциями, которые делаются для этой бизнес-операции.
ТаблоидalexeyvgТут всё просто - блокируете TurnoverTable и считаете, и никаких отрицательных остатков.вы про блокировку всей таблицы ? ну так это еще хуже, чем сейчас.Нет, не всей таблицы, а только для данных, по которым делается пересчёт.

Но конечено, т.к. пересчёт делается по актуальным данным, то этот метод будет более "блокирующим".

Собственно, таблицы остатков и придумали, чтобы уменьшить нагрузку и блокировки, а не наоборот :-)

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

Таблоидalexeyvg Если пользователи редактирует документы по минуте , то это операция не доставит проблем 240 000 одновременно работающим пользователям для 4-х ядерного проца.Нет, конечно :-) У нас ни у кого из юзеров нет "бесконтрольной блокировки" на строке (т.е. нет такого что он заблокировал строку и ушёл на обед).Я имел в виду, если каждый пользователь создаёт в среднем один документ в минуту.

ТаблоидВремя переноса количества между регистрами (по заранее выбранному изделию) минимальное, действительно там несколько ms.
Но вот клиент приезжает и ему надо расплачиваться за товар. Документ, все его NNN строк, должен быть ЦЕЛИКОМ переведен из статуса "Зарезервировано" в статус "Отгружено".
Перевод документа в другой статус - это не только движуха по двум регистрам каждой его строки. Как минимум там еще надо FIFO-цепочки выстроить по приходам, с которых "сдёргивается" каждая строка этого расхода. Еще надо обновить баланс и обороты контрагента, записать инфу в аудит, да много чего еще надо.
Я это к тому, что если в документе 300 строк, то эта операция уже не будет занимать миллисекунды - тут речь идет уже о нескольких секундах.Тут уже вопрос написания оптимального кода.

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

В общем, нужно просто всеми силами уменьшать время транзакции.

Ещё могу посоветовать откладывать самые критичные (блокирующие других) изменения на конец общей транзакции.

Ещё хороший способ уменьшить время блокировки - все вычисления, не требующие блокировки данных, выполнять перед началом общей транзакции.

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

Dimitry SibiryakovalexeyvgСобственно, таблицы остатков и придумали, чтобы уменьшить нагрузку и блокировки, а не наоборот :-)

Да, для СУБД в которых select-ы создают блокировки. Таковых, к счастью, теперь практически не осталось.
Нет, не для этого.

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

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

Просто абсурдно перерасчитывать для каждого чтения горы исторических данных.

Dimitry SibiryakovНо тут речь идёт о (грубо говоря) остатке на полночь плюс движение за сегодня.Я согласен, что в данном случае не критично.

Только вы-то говорили совсем другое: Таблицы остатков придумали для СУБД в которых select-ы создают блокировки.

А это не так.