Синхронизация работы клиентов

Здравствуйте господа. Есть БД на SQL сервер, клиенты работы с ней. Есть таблица T1, содержащая некоторое количество мат. ценностей по каждому клиенту, в таблице T2 хранится расход этих мат ценностей, тоже по каждому клиенту. Нельзя чтобы суммарное количество по клиенту в таблице Т2, превышало количество по клиенту в Т1. Однако, при одновременной выписке мат. ценностей на рабочих местах по одному и тому же клиенту такое возможно. Что можно сделать для того чтобы избежать такого ляпа. Обработка на триггере не подходит, так как я описал задачу утрированно - реальная обработка будет сильно тормозить. Может есть ещё какой-нибудь путь?

Ну естественно при проводке документа проверять на возможность недостачи
кол-ва с соотв. сообщением про проблему.
Придумать понятие резервирования кол-ва.
Кстати в некот. самодельных системах вааще нет понятия "проводка"... :)
У вас случайно не этот случай ??? :)

2UNIVERSAL
Вы говорите, что реальная обработка будет сильно тормозить, но всё-таки хотите проверять при сохранении. Противоречие. Пути:
1. Смириться с торможением
2. Отложенная проверка типа проводок.
3. Изменение схемы данных, что-бы не тормозило.

>Обработка на триггере не подходит, так как я описал задачу утрированно - реальная обработка будет сильно тормозить<

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

таким образом, в триггере было не меньше 15 операторов, большая часть из которых исполнялась всегда

к чему это я? - к тому, что отклик системы составлял менее 0.1 сек, что совершенно комфортно и приемлемо, и "будет сильно тормозить" оч., оч. спорно

Ещё раз про "тормозит". Суть - выписка продукции. Структура базы: Т1- счёт на предоплату (количество продукции), T2- выписанное количество продукции, Т3-доверенность (количество продукции), V1 - view, в которой получаем сальдо по каждому клиенту основа другая БД тоже на SQL. Для того чтобы определить максимально возможное количество для выписки мне надо пробежаться по Т1, Т3 и V1. Это довольно таки сильно отражается на скорости обновления данных в Т2. Пока везде в Т1, Т2, Т3 и V1 - записей несколько тысяч (около 10).

В смысле в каждой из таблиц и во вьюхе в пределах 10000 записей

это крохи, 10 тыс записей, я не замечал никаких проблем при наполнении бд за несколько лет примерно 20 милл. записей

Не знаю у меня 11 записей обновляются ~1-2 сек. Duration 1156 Я считаю это много. без триггера <1 сек.

Да и ещё базе только 4 мес. пошёл 5-ый

>Не знаю у меня 11 записей обновляются ~1-2 сек<

!!!
прокомментировать невозможно

какой сервер (конфигурация), ddl, dml, пример этих 11 записей ?