Доброво времени суток. Интересно решение я думаю классической проблемы: существует бд в которой производиться учёт и расход чего либо, расход и приход чеголибо осуществляеться по документам (например - акт прихода, накладная). В приложение при вводе документа стартует транзакция (при чём как я понял предыдущий разработчик сделал это для "Сохранить" "Отменить") в транзакции происходят изменения "шапки" документа (№ накладной, дата и т.д.) и табличной части документа (расход чего либо в определённом кол-ве). Проблемма собственнно заключаеться в том что при формирование расхода одним пользователем, другой пользователь может израсходовать (не увидив кол-во расхода другого пользователя) больше чем существует на cамом деле (с учётом расхода первого пользователя).
х - всего было
y1 - расход первого
y2 - расход второго
х-у1-у2>=0
На сколько я знаю особенности interbase не позволяют одной транзакции увидеть изменения другой?
проблема
ни одна нормальная СУБД не дает видеть изменения, которые не committed. Если dirty read (не поддерживаемый в IB/FB) не считать за уровень изолированности.На сколько я знаю особенности interbase не позволяют одной транзакции увидеть изменения другой?
нет такой проблемы. потому что расход в клиент-серверной СУБД делается не какПроблемма собственнно заключаеться в том что при формирование расхода одним пользователем, другой пользователь может израсходовать (не увидив кол-во расхода другого пользователя) больше чем существует на cамом деле (с учётом расхода первого пользователя).
ostatok = x
где x - предыдущее значение ostatok минус расход.
а как
ostatok = ostatok - rashod.
что при контроле ostatok > 0 например в триггере не дает "уменьшить" остаток ниже заданного.
p.s. Вам про транзакции еще бы почитать...
опишу поподробней бд:
есть таблица документов, таблица приходов, таблица расходов, ну и собственно некий справочник чего либо
при формировании прихода создаёться запись в таблице документ и записИ в таблицу приход с сулкой на документ
при формирование расхода создаёться запись в таблице документ и записИ в таблице расход с сылкой на документ и запись прихода с которого делаем расход
так уж реализованно в приложение что сначала создаёться пустая запись в таблице расхода а дальше она обновляеться с суммами и выбором чего либо - т.е. стоит тригер на изменение таблици расхода в котором собираються все расходы с этого прихода и сравниваються с тем что пришло. вычет не должен быть меньше нуля. вот так
есть таблица документов, таблица приходов, таблица расходов, ну и собственно некий справочник чего либо
при формировании прихода создаёться запись в таблице документ и записИ в таблицу приход с сулкой на документ
при формирование расхода создаёться запись в таблице документ и записИ в таблице расход с сылкой на документ и запись прихода с которого делаем расход
так уж реализованно в приложение что сначала создаёться пустая запись в таблице расхода а дальше она обновляеться с суммами и выбором чего либо - т.е. стоит тригер на изменение таблици расхода в котором собираються все расходы с этого прихода и сравниваються с тем что пришло. вычет не должен быть меньше нуля. вот так
Re: проблема
не совсем бы хотелось агрегатную таблицу с остатками, приложение огромное и позволяет решать серьёзные задаче в рамках предметной области (учёт металлопроката, автоматический подбор и комплектация металлопрокатом производственной документации+ порядка 50ти отчётов бухгалтерских и производственных) код разросся очень серьёзно сопровождать эту систему становиться всё сложней и сложней
Re: проблема
по поводу блокировок была такая идея- блокировать струку прихода с которой производиться расход и держать блокированной до момента комита транзакции, возможно ли средствами транзакции каким либо образом заблокировать доступ к строке (в другой транзакции) ?
Re: проблема
Как только наберёшь хотя бы пару миллионов записей, у тебя анализ остатков одной позиции будет занимать уже не милисекунды. А к десятку лимонов подберёшься - будет по полчаса документ записываться.funt писал(а):не совсем бы хотелось агрегатную таблицу с остатками, приложение огромное...
Не вижу, причём тут "серьёзность" задачи. Как будто я что-то лекгомысленное предлагаю.
Re: проблема
)) много работы будет если вводить таблицу агрегатную вот я к чеме про объём задачи оговорился, а по поводу скорости всё ок записей уже почти столько и есть- работает быстро!
Уважаемый, извиняюсь за комментарий, но нет сил больше смотреть на эти "создаёться", "обновляеться", "собираються", "сравниваються".
ни в одном этом слове мягкого знака быть не должно.
ни в одном этом слове мягкого знака быть не должно.
Это Ваше личное дело, внимать или нет. Никто Вас уговаривать сделать БД по человечески не заставляет. Хотите проблем и тормозов - шпарьте дальше в том же духе.много работы будет если вводить таблицу агрегатную вот
Re: проблема
Неудачная имхо идея.funt писал(а):по поводу блокировок была такая идея- блокировать струку прихода с которой производиться расход и держать блокированной до момента комита транзакции
Если что-то и блокировать, то только непосредственно при сохранении. Если кто создал документ и ушёл на обед (в командировку уехал), то фсё, товар более недоступен.
Читай статью о блокировках.funt писал(а):возможно ли средствами транзакции каким либо образом заблокировать доступ к строке (в другой транзакции) ?
-
Dimitry Sibiryakov
- Заслуженный разработчик
- Сообщения: 1436
- Зарегистрирован: 15 сен 2005, 09:05
-
Ivan_Pisarevsky
- Заслуженный разработчик
- Сообщения: 644
- Зарегистрирован: 15 фев 2005, 11:34
А чего ловить-то, могу привесть вполне жизненный пример:Dimitry Sibiryakov писал(а):Лучше бы поймать какого-нибудь специалиста по складам и узнать как эту задачу решают "ручками". Сильно подозреваю, что с помошью "резервации товара" и прочих лимитов.
Звонит(факс-емыло и т.п.) клиент в коммерческую службу, делает заказ, потом манагер (в часы пик бывало и 5 чел разом) сбыта отправляются на склад набрать товар, берется стойка и на нее заказанные лапсердаки/штанишки/сарафанчики и прочие фуфайки/рукавицы вешаются-складываются. После этого подзывается оператор склада, она берет ноут в левую руку, блютусный сканер штрихкода в правую и отправляется выписывать накладнуху, прощелкала она сканером все бирки (накладная готова, выписка идет не гляда на остатки) , упаковали это добро в коробки, по факту выезда коробок за ворота делается проводка-списание (меняются остатки соответственно).
Как-то так, конфликты минимальны (хотя бывало девки тырили друг у друга набранный товар
, что бывало легче заново прощелкать бирки, чем найти что утянули, но это баловство редкое), даже когда в августе валом прет школьная форма.-
Ivan_Pisarevsky
- Заслуженный разработчик
- Сообщения: 644
- Зарегистрирован: 15 фев 2005, 11:34
Приходи, как твои юзеры уйдут чайку попить.funt писал(а):всем спасибо проблема решена
использовал блокировку на выбранные записи прихода SELECT FOR UPDATE, и перед выбором холостой апдейтесли ок то ок если нет вываливаю сообщение о том что незя списать с него временно заблокированно
Оставив висеть заблокированными записи. 
Я чего зря чтоль сказки тебе на sql.ru рассказывал. 
-
Dimitry Sibiryakov
- Заслуженный разработчик
- Сообщения: 1436
- Зарегистрирован: 15 сен 2005, 09:05
