Проблема грязного чтения, как решить в SQL Server 2005

Question

Как я могу решить проблему грязного чтения ниже на сервере sql.

Есть клиент отчет по счетам, который запускается в 1:00 AM во второй половине дня, после чего все счета отправляются соответствующий клиент для платежей. Допустим, один из клиентов должен заплатить 1000 долларов. Покупатель платит 1000 $ в 1:00 утра и одновременно запускается отчет. На самом деле, у клиента нет денег в ожидании, но все еще выставлен счет.

также, как решить эту проблему, для неповторяемого чтения

Например, клиент хочет забронировать рейс, поэтому путешествие Агент проверяет наличие рейсов. Турагент находит место и идет вперед, чтобы забронировать место. Пока турагент бронирует место, другой туристический агент бронирует место. Когда это Турагент идет, чтобы обновить запись, он получает сообщение о том, что «место уже забронировано». Короче, турагент получает разный статус в разное время для моря

также эта проблема также беспокоит меня ... Потерянные обновления

Предположим, что клиент имеет 2000 $ к оплате. Он платит 1000 $ и снова покупает продукт за 500 $. Допустим, что эти два транзакции теперь вводятся с двух разных счетчиков компании. Теперь оба Пользователь счетчика начинает делать запись одновременно с 10:00. На самом деле в 10:01 утра клиент должен иметь 2000 $ -1000 $ + 500 = 1500 $ в ожидании оплаты. Но, как сказано в потерянных обновлениях первая транзакция не рассматривается, а вторая переопределяет ее. Итак, окончательное ожидание 2000 $ + 500 $ = 2500 $ ..... Я надеюсь, что компания не потеряет клиента.

Answer 1

Вы описываете логические дизъюнкции.

в последнем случае вам нужно составить счет и сказать, что клиент заплатил что-то, что не было сделано через систему, чтобы знать, что он это сделает.

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

Вы должны обработать ошибки.

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

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

Для этого есть все виды параллельных подходов - например, система семефоров. У самого sql есть транзакции. Параллелизм Google SQL, распространенная проблема со многими решениями.

Общий шаблон: чтение, блокировка, чтение, запись и разблокировка.

Понимание управления параллелизмом

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