Здравствуйте, LuciferNovoros, Вы писали:

LN>Здравствуйте, sushko, Вы писали:

LN>Ты про это?

Да, про это

LN>Тогда — короткие транзакции. Пусть себе клиент А сколь угодно пьет кофе и курит в курилке. Но реальные изменения происходить будут, как только он нажмет кнопку. То есть, ты вычитываешь для него количество товара, он его изменил и пошел курить. Клиент В в этот момент пусть себе продает — запись ведь не заблокирована! И как только клиент А нажимает кнопку, — стартует транзакция, подтверждающая его изменения.

Ничего не получится:

— В момент времени X программа считает, что на складе 10 единиц товара, и об этом знают клиенты А и Б
— В момент X+1 пользователь А пересчитывает к-во товара на полках и обнаруживает, что реально товара там только 8 штук. Пользователь А открывает диалоговое окно в климентском приложении для того, чтобы изменить к-во на реальное, и ставит в окошке ввода число 8, но OK не нажимает
— В момент X+2 пользователь B делает продажу и т.о. уменьшает остаток на единицу

UPDATE remainders SET remainder=remainder-1 WHERE id=?[sql]
- В момент X+3 пользователь А нажимает OK и т.о. запускает в базу запрос [sql]UPDATE remainders SET remainder=8 WHERE id=?

В результате мы будет иметь в БД остаток, равный 8, хотя по факту товара осталось 7 штук.

LN>З.Ы. А вообще я бы делал не так. Приход — одна таблица, расход — другая. А итоговая цифра просто результат вычислений по этим таблицам.

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

Здравствуйте, LuciferNovoros, Вы писали:

LN>Здравствуйте, sushko, Вы писали:

LN>Ты про это?

Да, про это

LN>Тогда — короткие транзакции. Пусть себе клиент А сколь угодно пьет кофе и курит в курилке. Но реальные изменения происходить будут, как только он нажмет кнопку. То есть, ты вычитываешь для него количество товара, он его изменил и пошел курить. Клиент В в этот момент пусть себе продает — запись ведь не заблокирована! И как только клиент А нажимает кнопку, — стартует транзакция, подтверждающая его изменения.

Ничего не получится:

— В момент времени X программа считает, что на складе 10 единиц товара, и об этом знают клиенты А и Б
— В момент X+1 пользователь А пересчитывает к-во товара на полках и обнаруживает, что реально товара там только 8 штук. Пользователь А открывает диалоговое окно в климентском приложении для того, чтобы изменить к-во на реальное, и ставит в окошке ввода число 8, но OK не нажимает
— В момент X+2 пользователь B делает продажу и т.о. уменьшает остаток на единицу

UPDATE remainders SET remainder=remainder-1 WHERE id=?

— В момент X+3 пользователь А нажимает OK и т.о. запускает в базу запрос

UPDATE remainders SET remainder=8 WHERE id=?

В результате мы будет иметь в БД остаток, равный 8, хотя по факту товара осталось 7 штук.

LN>З.Ы. А вообще я бы делал не так. Приход — одна таблица, расход — другая. А итоговая цифра просто результат вычислений по этим таблицам.

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