|
Диалог с пользователем в транзакции
|
|||
---|---|---|---|
#18+
Пользователь нажимает кнопку "Провести документ", стартует транзакция, и в базе происходит много чего, и в конце в этой же транзакции большой процедурой пересчитываются сводные показатели-агрегаты. По сравнению этих показателей становится понятно, что все не слишком хорошо, и по условию задачи пользователя об этом нужно переспросить, действительно ли он согласен на превышение таких-то показателей над такими-то на столько-то, или же он хочет откатить проведение. Показывать диалог и останавливаться прямо в транзакции, как известно, нехорошо, поскольку пользователь может уйти обедать, а транзакция большая и кое чего блокирует. Как тогда быть? Откатить транзакцию, выдать диалог, и в случае согласия опять ее запускать с флагом "Теперь не спрашивать", означающим согласие при проблемах? Но пока мы ждали, ситуация в БД могла сильно поменяться, и новое превышение может оказаться другим - скажем, гораздо больше, и если мы молча проведем документ, пользователь позже законно возмутится, что он именно на такое крупное безобразие согласия не давал. Получается, при переспросе надо запоминать все проблемные показатели, вызвавшие переспрос, и получив согласие пользователя, в повторной транзакции проверять, соответствуют ли текущие проблемные показатели тем, на что было получено согласие, и если да - продолжать, а нет - снова откатывать и снова переспрашивать? Неужели все так и делают? Как-то сложно получается, чувствую, переработался. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.12.2019, 13:27 |
|
Диалог с пользователем в транзакции
|
|||
---|---|---|---|
#18+
Cane Cat FisherПоказывать диалог и останавливаться прямо в транзакции, как известно, нехорошо, поскольку пользователь может уйти обедать, а транзакция большая и кое чего блокирует. Тем, кто продвинут чуть более, известно, что диалог можно показывать с тикающим тайм-аутом и он не относится к дизайну БД. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
06.12.2019, 14:04 |
|
Диалог с пользователем в транзакции
|
|||
---|---|---|---|
#18+
Cane Cat Fisher, Перевести документ в статус требует подтверждения и сделать доступным пользователю опцию провести документ в в любом случае, когда пользователь будет повторно проводить документ и будет ли устанавливать эту опцию зависит только от пользователя. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.12.2019, 14:13 |
|
Диалог с пользователем в транзакции
|
|||
---|---|---|---|
#18+
Cane Cat Fisher Неужели все так и делают? Как-то сложно получается, чувствую, переработался. Вообще говоря, это вопрос не проектирования, а бизнес-процесса. Но я бы ответил - стоит проще: закоммитить транзакцию с признаком "превышение не подтверждено", а в интерфейсе дать пользователю список неподтверждённых превышений и кнопку "сторнировать". ... |
|||
:
Нравится:
Не нравится:
|
|||
06.12.2019, 20:54 |
|
Диалог с пользователем в транзакции
|
|||
---|---|---|---|
#18+
Cane Cat Fisher, Винда перед копированием проверяет наличие необходимого свободного места на диске и выдаст ошибку если его не достаточно. Это не значит, что оно перещитывает все файлы каждый раз. Необходимый агрегат уже хранится в системе. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.12.2019, 21:30 |
|
Диалог с пользователем в транзакции
|
|||
---|---|---|---|
#18+
Relic Hunter Винда перед копированием проверяет наличие необходимого свободного места на диске и выдаст ошибку если его не достаточно. Это не значит, что оно перещитывает все файлы кажный раз. Необходий агрегат уже хранится в системе. Пример, имхо, неудачный. Не знаю, как делает винда, а по-хорошему, нужно резервировать место на диске и лишь при успехе этой операции - выдавать добро на, собственно, копирование. Впрочем, и это верно только если диск не упаковываемый на лету. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.12.2019, 21:34 |
|
Диалог с пользователем в транзакции
|
|||
---|---|---|---|
#18+
У некоторых наших клиентов документы снабжаются признаком "Утвержден". По тем, что не "Утвержден" - считаются предварительные итоги, а по тем, где "Утвержден" установлен - окончательные. Документ из одного состояния в другое не переводится, а создается клон, связанный с исходным (неутвержденным) вариантом. Ну там чуть посложнее процесс, но база такая. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.12.2019, 22:13 |
|
Диалог с пользователем в транзакции
|
|||
---|---|---|---|
#18+
Relic HunterВинда перед копированием проверяет наличие необходимого свободного места на диске Давно она начала так делать? Сколько помню, она всегда писала, писала, а ошибку выдавала только когда уже не могла записать очередной блок. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
06.12.2019, 22:13 |
|
Диалог с пользователем в транзакции
|
|||
---|---|---|---|
#18+
Dimitry Sibiryakov Relic HunterВинда перед копированием проверяет наличие необходимого свободного места на диске Давно она начала так делать? Сколько помню, она всегда писала, писала, а ошибку выдавала только когда уже не могла записать очередной блок. Дисятка так делает, по-крайней мере. Постоянно на это нарываюсь. Смешно когда пытаешься восстановить проводником папку из бекапа (места на диске не осталось или очень мало), т.е. сделать skip иле overwrite пишет, что мало места и обламывается. Из командной строки копирование проходит ))) ... |
|||
:
Нравится:
Не нравится:
|
|||
06.12.2019, 23:25 |
|
Диалог с пользователем в транзакции
|
|||
---|---|---|---|
#18+
softwarer по-хорошему, нужно резервировать место на диске и лишь при успехе этой операции - выдавать добро на, собственно, копирование. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.12.2019, 23:29 |
|
Диалог с пользователем в транзакции
|
|||
---|---|---|---|
#18+
У вас что-то там в целом не так, если процесс на полдня требует заключать его в транзакцию БД. авторТем, кто продвинут чуть более, известно, что диалог можно показывать с тикающим тайм-аутом Диалог с должником, который не может долг вернуть? ... |
|||
:
Нравится:
Не нравится:
|
|||
07.12.2019, 10:44 |
|
Диалог с пользователем в транзакции
|
|||
---|---|---|---|
#18+
Это прэлестно, просто прелестно. Т.е. имеется незакрытая транзакция и в базе происходит много чего, и в конце в этой же транзакции большой процедурой пересчитываются сводные показатели-агрегаты Т.к. транзакция не закрыта, в этом момент все остальные пользователи как бы на паузе танцуют индийские танцы, никуда не спешат и песней с танцем подбадривают юзера. Я думал, такие кейсы в докладах только в шутку приводят. Хотя, наверное самое то для цифровизации гос систем. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.12.2019, 02:19 |
|
Диалог с пользователем в транзакции
|
|||
---|---|---|---|
#18+
Trogloditтранзакция не закрыта, в этом момент все остальные пользователи как бы на паузе танцуют индийские танцы Я был уверен, что блокировочники уже умерли естественной смертью. На какой свалке истории Вы такое поведение откопали? Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
08.12.2019, 02:26 |
|
Диалог с пользователем в транзакции
|
|||
---|---|---|---|
#18+
Dimitry Sibiryakov Я был уверен, что блокировочники уже умерли естественной смертью. На какой свалке истории Вы такое поведение откопали? А при чем тут блокировочник/неблокировочник? Типа, если у тебя версионник, то писать двухнедельные транзакции сразу становится нормой? Тут выше правильно писали, что в приведенном случае проблема вообще не техническая, а в самом БП. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.12.2019, 05:27 |
|
Диалог с пользователем в транзакции
|
|||
---|---|---|---|
#18+
Dimitry Sibiryakov Я был уверен, что блокировочники уже умерли естественной смертью. На какой свалке истории Вы такое поведение откопали? А как по вашему будет поведение в базе происходит много чего, и в конце в этой же транзакции большой процедурой пересчитываются сводные показатели-агрегаты Очевидно по первому сообщению, что остальные пользователи не только читают, но и пишут в БД в одной транзакции, т.е. совершают похожие или такие же действия, рассчитывая те самые агрегаты, т.е. большое кол-во записей. Поэтому блокировки будут, как я и писал выше или в ваши версионники гадальные шары завезли? Про побочное ущерб в виде увеличения необходимого дискового пространства, падение производительности по io я уже и не говорю. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.12.2019, 11:33 |
|
Диалог с пользователем в транзакции
|
|||
---|---|---|---|
#18+
TrogloditПоэтому блокировки будут, как я и писал выше или в ваши версионники гадальные шары завезли? В наши версионники завезли рецепт агрегатов без блокировок. Но он, конечно, не всеми может быть осилен, да. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
08.12.2019, 13:34 |
|
Диалог с пользователем в транзакции
|
|||
---|---|---|---|
#18+
Dimitry Sibiryakov В наши версионники завезли рецепт агрегатов без блокировок. Но он, конечно, не всеми может быть осилен, да. Что ты имеешь ввиду под агрегатами без блокировок? ... |
|||
:
Нравится:
Не нравится:
|
|||
08.12.2019, 14:39 |
|
Диалог с пользователем в транзакции
|
|||
---|---|---|---|
#18+
iOracleDevЧто ты имеешь ввиду под агрегатами без блокировок? Хранимые агрегаты, поддержание которых в многопользовательской среде не приводит к блокировкам и конфликтам обновлений. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
08.12.2019, 14:41 |
|
Диалог с пользователем в транзакции
|
|||
---|---|---|---|
#18+
Cane Cat Fisher Пользователь нажимает кнопку "Провести документ", стартует транзакция, и в базе происходит много чего, и в конце в этой же транзакции большой процедурой пересчитываются сводные показатели-агрегаты. По сравнению этих показателей становится понятно, что все не слишком хорошо, и по условию задачи пользователя об этом нужно переспросить, действительно ли он согласен на превышение таких-то показателей над такими-то на столько-то, или же он хочет откатить проведение. Какая разница бухгалтеру, какие там получаются "превышения", если яблоки уже проданы и на расходной накладной есть подпись\печать покупателя? Cane Cat Fisher Но пока мы ждали, ситуация в БД могла сильно поменяться, и новое превышение может оказаться другим - скажем, гораздо больше, и если мы молча проведем документ, пользователь позже законно возмутится, что он именно на такое крупное безобразие согласия не давал. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.12.2019, 14:48 |
|
Диалог с пользователем в транзакции
|
|||
---|---|---|---|
#18+
Cane Cat Fisher Но пока мы ждали, ситуация в БД могла сильно поменяться, и новое превышение может оказаться другим - скажем, гораздо больше, и если мы молча проведем документ, пользователь позже законно возмутится, что он именно на такое крупное безобразие согласия не давал. На момент когда вы проводите документ, другие транзакции изменяющие показатели могли быть незафиксированы, при расчете все показатели в норме, документ провели, транзакцию зафиксировали, после этого другие пользователи подтвердили свои изменения, в результате при повторном просчете по документу, окажется что проводить его было нельзя, вы такую ситуацию рассматривали? ... |
|||
:
Нравится:
Не нравится:
|
|||
08.12.2019, 14:48 |
|
Диалог с пользователем в транзакции
|
|||
---|---|---|---|
#18+
Dimitry Sibiryakov Хранимые агрегаты, поддержание которых в многопользовательской среде не приводит к блокировкам и конфликтам обновлений. Первый раз слышу о таких агрегатах, пример пожалуйста приведите агрегата который будет удовлетворять read commited без блокировок и сериализации. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.12.2019, 14:51 |
|
Диалог с пользователем в транзакции
|
|||
---|---|---|---|
#18+
Gerros Как-то неправильно у вас в системе трактуется проведение документа. Есть документ, подтверждающий хозяйственную операцию. Вы слишком узко понимаете "документ". Представьте себе, например, что документ - это коммерческое предложение или вообще договор-оферта. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.12.2019, 14:55 |
|
Диалог с пользователем в транзакции
|
|||
---|---|---|---|
#18+
iOracleDevПервый раз слышу о таких агрегатах, пример пожалуйста приведите агрегата который будет удовлетворять read commited без блокировок и сериализации. Эти агрегаты невозможны в read committed, они работают только в snapshot. https://www.sql.ru/forum/964534/hranimye-agregaty-bez-konfliktov-i-blokirovok-recept Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
08.12.2019, 15:08 |
|
Диалог с пользователем в транзакции
|
|||
---|---|---|---|
#18+
softwarer Вы слишком узко понимаете "документ". Представьте себе, например, что документ - это коммерческое предложение или вообще договор-оферта. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.12.2019, 15:11 |
|
Диалог с пользователем в транзакции
|
|||
---|---|---|---|
#18+
Dimitry Sibiryakov Эти агрегаты невозможны в read committed Т.е. неконсистентный агрегат и что в итоге вы хотели сказать? ... |
|||
:
Нравится:
Не нравится:
|
|||
08.12.2019, 15:22 |
|
Диалог с пользователем в транзакции
|
|||
---|---|---|---|
#18+
Dimitry Sibiryakov iOracleDevЧто ты имеешь ввиду под агрегатами без блокировок? Хранимые агрегаты, поддержание которых в многопользовательской среде не приводит к блокировкам и конфликтам обновлений. Как это решит проблему, если два пользователя параллельно изменили один и тот же агрегат (каждый свою копию/версию) и оба хотят потом свои изменения сохранить? Чьи изменения сохранять - того, кто по должности старше, у кого денег больше / тачка круче / жена моложе, или просто того, у кого писюн длинее? ... |
|||
:
Нравится:
Не нравится:
|
|||
08.12.2019, 15:33 |
|
Диалог с пользователем в транзакции
|
|||
---|---|---|---|
#18+
Gerros А какие проводки должны формироваться для коммерческого предложения? Не обязательно проводки в хозяйственном смысле. Ну просто пример из головы. Допустим, я занимаюсь гастролями всяких артистов. И вот, я сижу и пишу письмо в Самару: "Чуваки, к вам может приехать спектакль "Буратино", в любой день с 15 до 20 декабря, условия такие-то". В тот момент, когда я собираюсь это письмо отправить, система должна просчитать, что в этот период на каждую роль в спектакле найдётся хотя бы один исполнитель, который её играет. Допустим, там играет актёр Артемонов. Это значит, что в момент отправки моего коммерческого предложения в базу должно лечь что-то, что позволит другому менеджеру написать коммерческое предложение на другой спектакль (включающий Артемонова) на 21-го число в Самару - и не позволит тому же менеджеру того же 21-го числа позарез нуждаться в Артемонове во Владивостоке. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.12.2019, 15:49 |
|
Диалог с пользователем в транзакции
|
|||
---|---|---|---|
#18+
iOracleDevТ.е. неконсистентный агрегат и что в итоге вы хотели сказать? Именно то,что и сказал: не всякий осилит. fkthatКак это решит проблему, если два пользователя параллельно изменили один и тот же агрегат (каждый свою копию/версию) и оба хотят потом свои изменения сохранить? Обоих. Потому что сохраняется не сам агрегат, а дельта к нему. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
08.12.2019, 16:14 |
|
Диалог с пользователем в транзакции
|
|||
---|---|---|---|
#18+
fkthat Как это решит проблему, если два пользователя параллельно изменили один и тот же агрегат (каждый свою копию/версию) и оба хотят потом свои изменения сохранить? Чьи изменения сохранять - того, кто по должности старше, у кого денег больше / тачка круче / жена моложе, или просто того, у кого писюн длинее? Я вот тоже не понял, ну сработает триггер, но транзакция так и останется не завершенной как для основной таблицы, так и для агрегата,пойдут локи или что-то не понимаю? А потом еще и присмотрелся, там еще и агрегат надо агрегировать во вью. Что-то какая то пиррова победа даже если все работать будет как было описано. Если мы говорим, что у нас агрегат может быть не консистентным, а по факту так и кажется (не только мне), то я бы смотрел в сторону мат. вью.,но это не точно. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.12.2019, 16:28 |
|
Диалог с пользователем в транзакции
|
|||
---|---|---|---|
#18+
Dimitry Sibiryakov Именно то,что и сказал: не всякий осилит. Вы предложили неконсистентный агрегат, он отличается от агрегата получаемого простым запросом без блокировок только перераспределением нагрузки на вычисление, где профит, где транзакционность? ... |
|||
:
Нравится:
Не нравится:
|
|||
08.12.2019, 16:36 |
|
Диалог с пользователем в транзакции
|
|||
---|---|---|---|
#18+
iOracleDevгде профит, где транзакционность? Скорость. Благодаря свёртке запрос лопатит гораздо меньше записей. Нет деградации производительности при накоплении данных. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
08.12.2019, 16:45 |
|
Диалог с пользователем в транзакции
|
|||
---|---|---|---|
#18+
softwarer, Не очень хороший пример, основываясь на предположении без подтверждения блокировать ресурс не очень хорошая практика. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.12.2019, 16:50 |
|
Диалог с пользователем в транзакции
|
|||
---|---|---|---|
#18+
Dimitry Sibiryakov Скорость. Благодаря свёртке запрос лопатит гораздо меньше записей. Нет деградации производительности при накоплении данных. Однако использование физической таблицы и постоянные процедуры пересчета, удаления и добавления записей, могут привести к увеличению нагрузки на систему по сравнению с выполнением обычных запросов, поэтому профит сомнительный. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.12.2019, 16:56 |
|
Диалог с пользователем в транзакции
|
|||
---|---|---|---|
#18+
Dimitry Sibiryakov Обоих. Потому что сохраняется не сам агрегат, а дельта к нему. Да какая разница дельта или хоть ипсилон - пришел Вася записал одно, пришел Петя, записал другое, следом пришел Вова, и что он должен в результате увидеть? Или ты ему дельты показывать будешь, а дальше сам пускай разбирается. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.12.2019, 17:26 |
|
Диалог с пользователем в транзакции
|
|||
---|---|---|---|
#18+
iOracleDevпостоянные процедуры пересчета, удаления и добавления записей, могут привести к увеличению нагрузки на систему по сравнению с выполнением обычных запросов Не могут. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
08.12.2019, 17:43 |
|
Диалог с пользователем в транзакции
|
|||
---|---|---|---|
#18+
softwarer Gerros А какие проводки должны формироваться для коммерческого предложения? Не обязательно проводки в хозяйственном смысле. Ну просто пример из головы. Допустим, я занимаюсь гастролями всяких артистов. И вот, я сижу и пишу письмо в Самару: "Чуваки, к вам может приехать спектакль "Буратино", в любой день с 15 до 20 декабря, условия такие-то". В тот момент, когда я собираюсь это письмо отправить, система должна просчитать, что в этот период на каждую роль в спектакле найдётся хотя бы один исполнитель, который её играет. Допустим, там играет актёр Артемонов. Это значит, что в момент отправки моего коммерческого предложения в базу должно лечь что-то, что позволит другому менеджеру написать коммерческое предложение на другой спектакль (включающий Артемонова) на 21-го число в Самару - и не позволит тому же менеджеру того же 21-го числа позарез нуждаться в Артемонове во Владивостоке. Ваш кейс аналогичен простой покупке товара. Вы предлагаете резервирование товара на момент отправки коммерческого предложения, так никто практически не работает. Предоплата, резерв, отгрузка. Так же и с Артемонами кончится тем, что никуда они не поедут и вы будете в убытках. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.12.2019, 17:45 |
|
Диалог с пользователем в транзакции
|
|||
---|---|---|---|
#18+
fkthatпришел Вася записал одно, пришел Петя, записал другое, следом пришел Вова, и что он должен в результате увидеть? В агрегате хранится "на складе 100 яблок". Пришёл Вася, записал "я продал 30 яблок". Пришёл Петя, записал "я продал 20 яблок". Ты не поверишь, но Вова увидит "на складе 50 яблок". И для этого системе придётся просуммировать только 3 записи, а не 100500 с начала времён. При этом ни Вова, ни Петя не увидят "подожди, там Вася ещё телится", хоть он неделю думай над сабжем. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
08.12.2019, 17:50 |
|
Диалог с пользователем в транзакции
|
|||
---|---|---|---|
#18+
TrogloditВы предлагаете резервирование товара на момент отправки коммерческого предложения, так никто практически не работает. Предоплата, резерв, отгрузка. А тут-то резерв зачем, раз товар уже оплачен? Он либо есть на складе и идёт сразу отгрузка, либо его на складе нет и идёт заказ у поставщика. Обычно (у тех же интернет-магазинов) товар как раз резервируется в момент заказа, а у некоторых он ещё при этом и отправляется к месту выдачи. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
08.12.2019, 17:57 |
|
Диалог с пользователем в транзакции
|
|||
---|---|---|---|
#18+
softwarer Допустим, я занимаюсь гастролями всяких артистов. И вот, я сижу и пишу письмо в Самару: "Чуваки, к вам может приехать спектакль "Буратино", в любой день с 15 до 20 декабря, условия такие-то". В тот момент, когда я собираюсь это письмо отправить, система должна просчитать, что в этот период на каждую роль в спектакле найдётся хотя бы один исполнитель, который её играет. Допустим, там играет актёр Артемонов. Это значит, что в момент отправки моего коммерческого предложения в базу должно лечь что-то, что позволит другому менеджеру написать коммерческое предложение на другой спектакль (включающий Артемонова) на 21-го число в Самару - и не позволит тому же менеджеру того же 21-го числа позарез нуждаться в Артемонове во Владивостоке. Такие задачи называются "Управление запасами" и решаются по-другому. Вообще по-другому: Менеджеры рассылают предложения (при этом в системе ничего не меняется). Менеджеры получают ответы (при этом в системе ничего не меняется). Менеджеры собираются на совещание и составляют план-график. Целевая функция - ну, например, максимальная прибыль за период. План-график согласуется с заказчиками, снова меняется и так по кругу. Заключаются договоры с заказчиками. Чуваки едут, показывают, подписывают акт выполненных работ. Акт выполненных работ ПРОВОДИТСЯ (при этом в системе списываются все расходы и появляется дебеторская задолженность заказчика). Вычисление целевой функции конечно лучше автоматизировать, но зачем при этом блокировать ресурсы? ... |
|||
:
Нравится:
Не нравится:
|
|||
08.12.2019, 18:20 |
|
Диалог с пользователем в транзакции
|
|||
---|---|---|---|
#18+
Dimitry Sibiryakov В агрегате хранится "на складе 100 яблок". Вот версионник без блокировки: В агрегате хранится "на складе 100 яблок". Утром: Пришёл Вася, спросил "сколько у нас яблок" - ему сказали "100", он ушел довольный Пришёл Петя, спросил "сколько у нас яблок" - ему сказали "100", он ушел довольный Вечером: приходит Вася "я продал Мише 70 яблок" приходит Петя: "а я продал Маше 80 яблок" На следующее утро: Приходят вместе Миша с Машей с накладными на 70 + 180 = 150 яблок. И кладовщик-версионник мечется между четыремя персонажами ожидая, что его кто-то из них вот-вот выи..ет, чтобы он недостающие 50 яблок родил. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.12.2019, 18:37 |
|
Диалог с пользователем в транзакции
|
|||
---|---|---|---|
#18+
fkthatего кто-то из них вот-вот выи..ет, чтобы он недостающие 50 яблок родил. Угу. Только не его, а того горе-менеджера, который просрал точку пополнения запасов на популярный товар. И не "родил", а послал поставщику срочный заказ, а Маше - извинение, что её заказ задерживается в связи с техническими проблемами. Ну а наивному разработчику системы, который надеялся, что данные в ней всегда соответствуют действительности и не послал этому менеджеру уведомление о том, что запасы снизились на критический уровень - дать по шапке. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
08.12.2019, 18:56 |
|
Диалог с пользователем в транзакции
|
|||
---|---|---|---|
#18+
Dimitry Sibiryakov А тут-то резерв зачем, раз товар уже оплачен? Он либо есть на складе и идёт сразу отгрузка, либо его на складе нет и идёт заказ у поставщика. Обычно (у тех же интернет-магазинов) товар как раз резервируется в момент заказа, а у некоторых он ещё при этом и отправляется к месту выдачи. У всех все по разному, резерв нужен для ожидания например подвоза товара, который партнерский например, но в то же время чтобы не умыкнули другому покупателю, поэтому пока отгрузки нет, он в резерве, и это я обрисовал простенькую схему, у зубров все посложнее. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.12.2019, 19:21 |
|
Диалог с пользователем в транзакции
|
|||
---|---|---|---|
#18+
Dimitry Sibiryakov В агрегате хранится "на складе 100 яблок". Пришёл Вася, записал "я продал 30 яблок". Пришёл Петя, записал "я продал 20 яблок". Ты не поверишь, но Вова увидит "на складе 50 яблок". И для этого системе придётся просуммировать только 3 записи, а не 100500 с начала времён. При этом ни Вова, ни Петя не увидят "подожди, там Вася ещё телится", хоть он неделю думай над сабжем. Так Вася еще не записал. Он в процессе или мы про грязное чтение говорим? При этом есть запись на insert/update от васи на без коммита и по расписанию удаление всех записей, т.е. она будет удалена/проигнорирована/я есть грут? ... |
|||
:
Нравится:
Не нравится:
|
|||
08.12.2019, 19:25 |
|
Диалог с пользователем в транзакции
|
|||
---|---|---|---|
#18+
TrogloditПри этом есть запись на insert/update от васи на без коммита и по расписанию удаление всех записей, т.е. она будет удалена/проигнорирована/я есть грут? Свёртка производится в snapshot транзакции, поэтому она удалит только те записи, которые свернула. Если Вася не закоммитился - его записи для этой транзакции не существует. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
08.12.2019, 19:36 |
|
Диалог с пользователем в транзакции
|
|||
---|---|---|---|
#18+
Dimitry Sibiryakov Не могут. В условиях отсутствия конкретной информации по распределению данных и частоте выполнения запросов, ваше утверждение бессмысленно. Dimitry Sibiryakov Угу. Только не его, а того горе-менеджера, который просрал точку пополнения запасов на популярный товар. И не "родил", а послал поставщику срочный заказ, а Маше - извинение, что её заказ задерживается в связи с техническими проблемами. Ну а наивному разработчику системы, который надеялся, что данные в ней всегда соответствуют действительности и не послал этому менеджеру уведомление о том, что запасы снизились на критический уровень - дать по шапке. Какая глупость, при чем тут какой то менеджер, система не должна дать продать отсутствующий товар, здесь вина исключительно бестолкового архитектора системы. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.12.2019, 19:59 |
|
Диалог с пользователем в транзакции
|
|||
---|---|---|---|
#18+
iOracleDevсистема не должна дать продать отсутствующий товар Наивно. Информация в компьютерной системе никогда не соответствует реальности. Она технически не может проконтролировать наличие или отсутствие товара. Максимум, что она может - намекнуть, что товара может в реальности не быть. Но начинать делать это она должна задолго до того, как какой-то хранимый агрегат достигнет нуля. И по той же причине она не должна препятствовать продаже товара по его (нуля) достижении. Согласись, как автор POS, ты будешь выглядеть глупо, когда в "твоём" супермаркете тебе не смогут пробить товар, который ты держишь в руках, только потому, что твоя система считает, что тот уже кончился. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
08.12.2019, 20:11 |
|
Диалог с пользователем в транзакции
|
|||
---|---|---|---|
#18+
Dimitry Sibiryakov Информация в компьютерной системе никогда не соответствует реальности. Она технически не может проконтролировать наличие или отсутствие товара. Максимум, что она может - намекнуть, что товара может в реальности не быть. Но начинать делать это она должна задолго до того, как какой-то хранимый агрегат достигнет нуля. И по той же причине она не должна препятствовать продаже товара по его (нуля) достижении. Согласись, как автор POS, ты будешь выглядеть глупо, когда в "твоём" супермаркете тебе не смогут пробить товар, который ты держишь в руках, только потому, что твоя система считает, что тот уже кончился. Да, может расходиться, поэтому существует такой процесс как инвентаризация. И тем не менее системы препятствуют продаже товара если его на складе (по информации в системе) больше нет, его не смогут пробить на кассе, странно что вы с этим не сталкивались. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.12.2019, 20:25 |
|
Диалог с пользователем в транзакции
|
|||
---|---|---|---|
#18+
Dimitry Sibiryakov Согласись, как автор POS, ты будешь выглядеть глупо, когда в "твоём" супермаркете тебе не смогут пробить товар, который ты держишь в руках, только потому, что твоя система считает, что тот уже кончился. Согласитесь, как автор оптового учета,вы будете выглядеть глупо, когда выписан счет, оплачено приехал купец за товаром, а в "вашей" конторе товара нет на остатках, только потому что ваша система считает, что тот еще не кончился. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.12.2019, 20:38 |
|
Диалог с пользователем в транзакции
|
|||
---|---|---|---|
#18+
Dimitry Sibiryakov Свёртка производится в snapshot транзакции, поэтому она удалит только те записи, которые свернула. Если Вася не закоммитился - его записи для этой транзакции не существует. Это просто праздник какой то. Т.е. если у нас агрегат из остатков превращается в комбинацию агрегаций вирт. остатка(ваш остаток)+товар в пути+зарезервированный товар+брак+.... и это все должно быть консистентно, и по каждому создавать агрегатную вьюху, задания на чистку, join'ы для запросов. Это музыка, достойная HighLoad'a. А если мы говорим не про остатки, а например про границы размера товарного кредита клиенту, его тоже надо позволять за рамки уводить? Т.е. пока Вася на телефоне втирает представителю клиента на 50млн, Петя подсуетился и договорился с другим баером этого же клиента на 50млн. Вася закоммитил все, и имеем товарный кредит в 100млн, при границе например в 60. Вот владелец то обрадуется, когда ему про "как космические снапшоты будут бороздить пространство" будут рассказывать. А если применить социальную инженерию, как только народ поймет, что "это чо то там снапшоты понаделали" прокатывают, утащут ВСЕ и ВСЁ. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.12.2019, 20:44 |
|
Диалог с пользователем в транзакции
|
|||
---|---|---|---|
#18+
Dimitry Sibiryakov, Я бы вашу идею с аггрегатами, ведь она не настолько плоха, дополнил и упростил. 1. Эти агрегаты нельзя использовать для формирования первички. 2. Отличный вариант для кэшей, но без вью, корретировочных процедур. 2.a. Сторонным софтом заполняем агрегаты поредством подписки на event'ы. Не знаю как в птице,например в postgres'е event вызывается только ПОСЛЕ коммита. 2.b В конце транзакции вызывет уведомления для event'a. И блокировок уже не будет. Но повторюсь использовать эти данные в учете нельзя. Для аналитики, статистики, мониторинга и пр. очень даже неплохо. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.12.2019, 21:07 |
|
Диалог с пользователем в транзакции
|
|||
---|---|---|---|
#18+
Troglodit, Смысл идеи - убрать лишние записи периодически схлопывая дельты, это один из способов оптимизировать скорость выполнения запроса для подсчета агрегата, имеет смысл, когда записей по агрегируемой группе очень очень много, а запрос выполняется очень часто. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.12.2019, 21:59 |
|
Диалог с пользователем в транзакции
|
|||
---|---|---|---|
#18+
iOracleDev Troglodit, Смысл идеи - убрать лишние записи периодически схлопывая дельты, это один из способов оптимизировать скорость выполнения запроса для подсчета агрегата, имеет смысл, когда записей по агрегируемой группе очень очень много, а запрос выполняется очень часто. Это я понял, но можно и без схлопывания, тупо мержить запись. В моем предложении, когда нам консистентность на 100% не нужна,блокировок на мерж записей ПОСЛЕ коммита не будет. Просто реализация - это отказ от ACID. Решение: а давайте возьмем и выбросим все эти транзакции на помойку. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.12.2019, 22:04 |
|
Диалог с пользователем в транзакции
|
|||
---|---|---|---|
#18+
Troglodit, У таблицы расчета агрегата смысл только один, если записей по агрегируемой группе миллион, то в таблице с рассчитанным агрегатом будет всего одна, оперативные изменения будут входить в нее в виде дельт, которые будут периодически процедурой схлопываться в одну, таким образом вместо суммирования по миллиону записей, суммирование будет идти по одной записи с готовой суммой плюс еще не схлопнутые дельты. Без процедуры схлопывания дельт выигрыша в скорости нет и смысла в такой конструкции также нет. Подобная конструкция ткже усложняет дальнейшую поддержку системы. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.12.2019, 22:17 |
|
Диалог с пользователем в транзакции
|
|||
---|---|---|---|
#18+
iOracleDev Troglodit, У таблицы расчета агрегата смысл только один, если записей по агрегируемой группе миллион, то в таблице с рассчитанным агрегатом будет всего одна, оперативные изменения будут входить в нее в виде дельт, которые будут периодически процедурой схлопываться в одну, таким образом вместо суммирования по миллиону записей, суммирование будет идти по одной записи с готовой суммой плюс еще не схлопнутые дельты. Без процедуры схлопывания дельт выигрыша в скорости нет и смысла в такой конструкции также нет. Подобная конструкция ткже усложняет дальнейшую поддержку системы. Да это все понятно я, я к тому что вместо 3х позиций Пети,Васи,Вани по одному агрегату как предлагали выше, должно схлопываться(мержиться) в ОДНУ запись, и тогда на ни вью с суммой по агрегату, ни периодическая чистка а перед этим агрегация, не нужна. Т.е. вместо В агрегате хранится "на складе 100 яблок". Пришёл Вася, записал "я продал 30 яблок", В агрегате хранится "на складе 70 яблок" Пришёл Петя, записал "я продал 20 яблок", В агрегате храниться "на складе 50 яблок" Никаких дополнительных строк по яблокам, мы просто меняем остаток по яблокам. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.12.2019, 23:15 |
|
Диалог с пользователем в транзакции
|
|||
---|---|---|---|
#18+
iOracleDev Не очень хороший пример, основываясь на предположении без подтверждения блокировать ресурс не очень хорошая практика. Говорить "ой, извините, мы не можем выполнить то, что сами же вам и предложили, а вы вдруг взяли и согласились" - практика ещё хуже. Пример, конечно, нарочитый и упрощённый, но несёт именно то, что я хотел изложить в свете слов топикстартера - "сложный агрегат" (расписание кто когда где может быть занят) считается на ходу и может привести к предупреждениям и решению приостановить или отменить вроде бы выдвинутый документ. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.12.2019, 23:33 |
|
Диалог с пользователем в транзакции
|
|||
---|---|---|---|
#18+
Troglodit, При изменении одной и той же строки мы имеем сериализацию (блокировки), именно поэтому и было предложено хранить дельты В агрегате хранится "на складе 100 яблок". Пришёл Вася, записал "я продал 30 яблок", В агрегате хранится "на складе -30 яблок" Пришёл Петя, записал "я продал 20 яблок", В агрегате храниться "на складе -20 яблок" сумма по таблице агрегата даст 50. Отрабатывает периодическая процедура и остается одна строка В агрегате хранится "на складе 50 яблок". Пользователи могут только добавлять строки дельт, процедура меняет строку с итоговым агрегатом и удаляет строки, уже учтенные в итоговом агрегате, при этом изменения одних и тех же строк разными пользователями нет и процедура с ними тоже не пересекается. ... |
|||
:
Нравится:
Не нравится:
|
|||
09.12.2019, 01:19 |
|
Диалог с пользователем в транзакции
|
|||
---|---|---|---|
#18+
softwarer Говорить "ой, извините, мы не можем выполнить то, что сами же вам и предложили, а вы вдруг взяли и согласились" - практика ещё хуже. Пример, конечно, нарочитый и упрощённый, но несёт именно то, что я хотел изложить в свете слов топикстартера - "сложный агрегат" (расписание кто когда где может быть занят) считается на ходу и может привести к предупреждениям и решению приостановить или отменить вроде бы выдвинутый документ. Пример не жизненный и неудачный, поскольку в результате труппа остается без работы, а менеджер идет на улицу. ... |
|||
:
Нравится:
Не нравится:
|
|||
09.12.2019, 01:26 |
|
Диалог с пользователем в транзакции
|
|||
---|---|---|---|
#18+
iOracleDev Troglodit, При изменении одной и той же строки мы имеем сериализацию (блокировки), именно поэтому и было предложено хранить дельты В агрегате хранится "на складе 100 яблок". Пришёл Вася, записал "я продал 30 яблок", В агрегате хранится "на складе -30 яблок" Пришёл Петя, записал "я продал 20 яблок", В агрегате храниться "на складе -20 яблок" сумма по таблице агрегата даст 50. Отрабатывает периодическая процедура и остается одна строка В агрегате хранится "на складе 50 яблок". Пользователи могут только добавлять строки дельт, процедура меняет строку с итоговым агрегатом и удаляет строки, уже учтенные в итоговом агрегате, при этом изменения одних и тех же строк разными пользователями нет и процедура с ними тоже не пересекается. Блокировки будут безусловно (стандартные, но не те долгие, которые мы обсуждаем), но в нашем случае если использовать event'ы там все будет стандартно. Т.е. начало изменения агрегата будет происходить уже ПОСЛЕ коммита долгой транзакции, если будет откат вызов event'a не произойдет. Да мы жертвуем консистентностью, появляется вопрос, что делать если не смогли обработать event, но мне кажется это проще вариант с агрегированием агрегата во вью и периодическая чистка. ... |
|||
:
Нравится:
Не нравится:
|
|||
09.12.2019, 09:05 |
|
Диалог с пользователем в транзакции
|
|||
---|---|---|---|
#18+
па сабжу: По возможности сделать все возможные проверки до проведения. То, что нельзя проверить: пробуем провести документ с параметром " реагировать на ошибку ХХ". Если ошибка, то откатываем изменения и выводим соотв. сообщение. Если юзер подтверждает проведение с ошибкой, то снова проводить с параметром " Не реагировать на ошибку ХХ". ... |
|||
:
Нравится:
Не нравится:
|
|||
09.12.2019, 17:10 |
|
Диалог с пользователем в транзакции
|
|||
---|---|---|---|
#18+
Разве задача не стара как мир ? Как считать остатки товара на складе если пользователей 1000 и все продают с этого склада. Вариант 1. Отрицательные остатки разрешены - фиксируем совершенные бизнес-операции, разбираемся потом. Вариант 2. Отрицательные остатки не разрешены. Создаем стек транзакций, каждая транзакция считает возможность проведения операции. Если возможности нет - пользователю возвращается отрицательный результат и берется следующая транзакция их стека. Вы хотите придумать вариант 3? Зачем ? ... |
|||
:
Нравится:
Не нравится:
|
|||
12.12.2019, 12:03 |
|
Диалог с пользователем в транзакции
|
|||
---|---|---|---|
#18+
L_argo Если юзер подтверждает проведение с ошибкой, то снова проводить с параметром " Не реагировать на ошибку ХХ". Проблема этого подхода в том, что между двумя последовательными вызовами с базой параллельно работают и другие пользователи. Поэтому вполне может случиться так, что после "проведения с ошибкой" возникнет уже не ошибка XX, а ошибка YY (либо ошибка XX, но с другими числовыми значениями, которые пользователь уже не подтвердил бы). ... |
|||
:
Нравится:
Не нравится:
|
|||
12.12.2019, 14:00 |
|
Диалог с пользователем в транзакции
|
|||
---|---|---|---|
#18+
во блин, неужто непонятно что бабу можно одновременно только в несколько независимых дыр это максимум до чего дошел порнушный прогресс а так по очереди (и по хорошему - если согласна) ... |
|||
:
Нравится:
Не нравится:
|
|||
12.12.2019, 14:14 |
|
Диалог с пользователем в транзакции
|
|||
---|---|---|---|
#18+
softwarer L_argo Если юзер подтверждает проведение с ошибкой, то снова проводить с параметром " Не реагировать на ошибку ХХ". Проблема этого подхода в том, что между двумя последовательными вызовами с базой параллельно работают и другие пользователи. Поэтому вполне может случиться так, что после "проведения с ошибкой" возникнет уже не ошибка XX, а ошибка YY (либо ошибка XX, но с другими числовыми значениями, которые пользователь уже не подтвердил бы). Большинство обсуждаемых кейсов в большей степени надуманы. ХРРРРР!!! сказала пила..... Ааа пля, сказали рабочие (с) анек ... |
|||
:
Нравится:
Не нравится:
|
|||
12.12.2019, 14:36 |
|
Диалог с пользователем в транзакции
|
|||
---|---|---|---|
#18+
L_argo Если не установлен игнор ошибки YY, то будет откат и другое сообщение. :) О том и речь. Такой процесс склонен доходить до зашкаливающей степени идиотизма. ... |
|||
:
Нравится:
Не нравится:
|
|||
12.12.2019, 14:40 |
|
Диалог с пользователем в транзакции
|
|||
---|---|---|---|
#18+
softwarer L_argo Если не установлен игнор ошибки YY, то будет откат и другое сообщение. :) О том и речь. Такой процесс склонен доходить до зашкаливающей степени идиотизма. Если код правильно написан, то сообщение расскажет о всех ошибках, а не только о первой. Поэтапное появление ошибок вещь неприятная, но будет редко встречаться. А как по другому, если нужно знать решение пользователя ? ... |
|||
:
Нравится:
Не нравится:
|
|||
12.12.2019, 17:33 |
|
|
start [/forum/topic.php?all=1&fid=32&tid=1539889]: |
0ms |
get settings: |
11ms |
get forum list: |
14ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
48ms |
get topic data: |
13ms |
get forum data: |
3ms |
get page messages: |
98ms |
get tp. blocked users: |
2ms |
others: | 15ms |
total: | 212ms |
0 / 0 |