Здравствуйте, LuciferNovoros, Вы писали:
LN>Потому что не надо делать. От слова совсем. Надо сделать таблицы прихода и таблицы расхода товаров. Как я тебе уже и написал. И таблицу остатков, куда все это будет сводиться. Иначе у тебя получится полная хрень, когда несколько пользователей ломанутся обновлять одно и то же поле, которое в принципе не должно быть обновляемым напрямую, потому что оно должно быть вычисляемым.
В теории да. А на практике оно не может быть вычисляемым, т.к. на его вычисление уходят десятки минут — например, если мы считаем по базе из 60,000 наименований товаров, сотнях тысяч операций и слабеньком железе.
У классиков-теоретиков это называется "денормализация струкруты БД" — когда вычисляемые поля таки помещаются в БД как хранимые ради быстродействия системы в целом.
Здравствуйте, sushko, Вы писали:
S>Здравствуйте, BlackEric, Вы писали:
S>Я ожидал, что с WAIT транзакция клиента B из исходного сообщения выполнится после того, как клиент А снимет блокировку, а с параметром NOWAIT клиент B получит отлуп при попытке изменить заблокированную запись. В реальности же клиент B получает отлуп всегда, что с WAIT, что с NOWAIT. В чем тогда смысл этого параметра?
Здравствуйте, BlackEric, Вы писали:
S>>Я ожидал, что с WAIT транзакция клиента B из исходного сообщения выполнится после того, как клиент А снимет блокировку, а с параметром NOWAIT клиент B получит отлуп при попытке изменить заблокированную запись. В реальности же клиент B получает отлуп всегда, что с WAIT, что с NOWAIT. В чем тогда смысл этого параметра?
BE>Lock conflict on no wait transaction
Не наш случай. В приведенной Вами ссылке написано: It only happens when the current transaction is a NO WAIT transaction, тогда как в моем примере ексепшген получает как раз WAIT-транзакция.
Здравствуйте, sushko, Вы писали:
S>Не наш случай. В приведенной Вами ссылке написано: It only happens when the current transaction is a NO WAIT transaction, тогда как в моем примере ексепшген получает как раз WAIT-транзакция.
Здравствуйте, sushko, Вы писали:
S>В теории да. А на практике оно не может быть вычисляемым, т.к. на его вычисление уходят десятки минут — например, если мы считаем по базе из 60,000 наименований товаров, сотнях тысяч операций и слабеньком железе.
На практике оно вычисляться будет только при построении отчета. Ты делаешь это каждую минуту? Вот сильно сомневаюсь... У тебя 60 тысяч товаров реально ежеминутно находятся в движении? Вряд ли. Так что, сделай уже нормально. Иначе никакие параметры транзакций тебя не спасут.
S>У классиков-теоретиков это называется "денормализация струкруты БД" — когда вычисляемые поля таки помещаются в БД как хранимые ради быстродействия системы в целом.
Да, но это не тот случай.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Re[14]: [FireBird] deadlock; update conflicts with concurrent update
Здравствуйте, BlackEric, Вы писали:
S>>Не наш случай. В приведенной Вами ссылке написано: It only happens when the current transaction is a NO WAIT transaction, тогда как в моем примере ексепшген получает как раз WAIT-транзакция.
BE>Какая версия?
FireBird 2.5. Комплектацию (суперсервер там и т.п.) не помню, возможно, classic.
Здравствуйте, LuciferNovoros, Вы писали:
S>>В теории да. А на практике оно не может быть вычисляемым, т.к. на его вычисление уходят десятки минут — например, если мы считаем по базе из 60,000 наименований товаров, сотнях тысяч операций и слабеньком железе.
LN>На практике оно вычисляться будет только при построении отчета. Ты делаешь это каждую минуту? Вот сильно сомневаюсь...
Продавцу нужно знать, сколько товара есть в магазине, и сколько товара есть в других магазинах этой же сети. Т.е. эти цифры постоянно присутствуют на экране.
LN>У тебя 60 тысяч товаров реально ежеминутно находятся в движении? Вряд ли. Так что, сделай уже нормально. Иначе никакие параметры транзакций тебя не спасут.
Откуда я знаю, я же девелОпер, а не владелец магазина, и программа делается не под конкретного заказчика, а, так сказать, "для широкого круга потребителей".
S>>У классиков-теоретиков это называется "денормализация струкруты БД" — когда вычисляемые поля таки помещаются в БД как хранимые ради быстродействия системы в целом.
LN>Да, но это не тот случай.
Здравствуйте, sushko, Вы писали:
S>Продавцу нужно знать, сколько товара есть в магазине, и сколько товара есть в других магазинах этой же сети. Т.е. эти цифры постоянно присутствуют на экране.
Да не нужно ему этого знать. Если товара нет в наличии, то программа не должна разрешить ему продать. Все. Хотя, если сам хозяин за прилавком стоит, тогда другой вопрос.
S>Откуда я знаю, я же девелОпер, а не владелец магазина, и программа делается не под конкретного заказчика, а, так сказать, "для широкого круга потребителей".
А зря. Изучение предметной области — это первое, с чего следовало бы начать.
P.S. Как итог: 1С УТ спасет отца русской демократии. Без ищобретения велосипедов и прочих ортопедических изделий.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Re[5]: [FireBird] deadlock; update conflicts with concurrent
Здравствуйте, sushko, Вы писали:
S>Вообще, я не понимаю, о чем мы спорим. А заблокировал запись, В пытается ее изменить в WAIT-транзакции, и эта транзакция В подвисает до тех пор, пока не закончится транзакция А, и это правильно. Но почему-то по завершении транзакции А транзакция В не начинает работать, как можно было бы предположить по смыслу слова WAIT, а завершается с ошибкой. В чем тогда смысл параметра WAIT у транзакции В?
