У меня в проекте это не так редко, но скорее из-за специфики проекта. Суть процесса - планирование цен на ассортимент товаров. То есть деятельность целиком виртуальная (нет платёжки у конкретного бухгалтера, ящика на конкретном складе итп), при этом от выставленных цен зависят объёмы продаж, от продаж одного товара зависят продажи другого (грубо говоря, больше купят розовых футболок => меньше зелёных штанов), размещение на производстве одного заказа может занять мощности, помешать размещению другого и тем изменить его себестоимость, цены доставки зависят от объёмов, меняются и ими занимаются отдельные люди, одни люди занимаются товарами в разрезе категорий, другие - в разрезе брендов, третьи - в разрезе каналов, всё это должно вписываться в заданные рамки прибыльности итп... в общем, многомерная мешанина. А поскольку товары вдобавок бывают сезонные, поскольку у них разные сроки на разработку, заказ итп, в итоге не так редко получается так, что половина пользователей резко бросилась в один и тот же сегмент.


Проблема в том, что атрибуты нередко взаимосвязаны. Вася прочитал запись (Количество; Цена; Скидка) и поставил скидку за уровень свыше миллиона единиц, а Петя прочитал ту же запись (Количество; Цена; Скидка) и уменьшил количество до восьмисот тысяч.

Нет. Один товарищ управляет ценовой политикой, например, по ботинкам, и выставляет неким ботинкам свою цену. Другой товарищ управляет ценовой политикой, например, по бренду "Пьер Карден", и выставляет тем же ботинкам свою цену. Когда эти цены расходятся - ботинки висят в статусе, назовём его "Переговоры", пока они между собой не договорятся. Когда цены совпадают - их можно двинуть дальше, ну там в "Заказать". В это же время третий товарищ занимается, например, транспортными расходами и вбивает их в те же ботинки, дабы по ним можно было посчитать себестоимость и прибыль. То есть эти люди реально могут попытаться одновременно редактировать одну запись, это не такое исключительное событие конкретно в этой системе.


С чего вдруг? Пример, конечно, условный, но уменьшил он в интерфейсе и сохранил в БД.

Ну то есть вот условно: Петя видит, что запланирован миллион единиц товара, звонит Кардену и говорит: Пьер, я такой хороший клиент, что хочу заказать целый миллион ботинок, дай мне по этому поводу особую скидку. Договаривается, пробивает её в запись и идёт праздновать. В это же время Вася решает, что ботинок от Кардена многовато и решает уменьшить запланированный объём. А "умный мерж", описанный моим собеседником, молча объединяет эти изменения, в результате чего оказывается, что Кардена кинули, он в бешенстве и все немножечко обосрались.

Безусловно. Это просто пояснение к тому, почему в конкретной системе пользователи сравнительно часто сталкиваются на блокировках одной и той же записи. Особенности бизнес-процесса.


Ты ушёл куда-то не туда. Смотри. Есть запись, "ботинки от Кардена". В ней три поля: цена категорийного менеджера (редактирует первый чувак), цена бренд-менеджера (редактирует второй чувак), транспортные расходы (редактирует третий чувак). Естественно, это донельзя упрощённая картина, просто чтобы описать природу процесса, порождающего довольно частые столкновения на блокировках.


Блин, я ещё две реплики назад сказал: старое значение миллион, новое значение восемьсот тысяч. Что тут непонятного? Ты пишешь сначала одну дикую реплику, потом другую...


Я привёл тебе кейс, где такое - норма. Ты начал что-то про версионность.

Году в 2005-м я приехал к одному заказчику, и нашёл там местных айтишников, боровшихся с проблемой на другом проекте. Суть проблемы была в том, что пользователи выгружали счёт в pdf, руками правили в нём цифры и в таком виде отсылали клиенту. Причём делали они так потому, что поставить правильные цифры таким образом было элементарно проще, чем заставить систему их сформировать и выдать.

Так вот, только что я понял, каким образом рождаются такие системы.