Как организовать работу с картами клиентов (БД) в веб?

Question

[Евгений Иванов]

Есть сайт (веб приложение на php/python/asp), который работает с БД.
В БД хранятся данные, например медицинские карты клиентов.

Менеджеру в браузере загружается такая карта. И он может её редактировать, изменить ФИО...
Менеджеров много.
В результате, если два менеджера одновременно откроют одну карту, а потом её сохранят, то работа одного из них пропадет т.к. будет перезаписана менеджером, кто выполнил сохранение позднее.

В жизни существует одна карта. И такой ситуации обычно не возникает.
В GITе такая ситуация называется конфликтом, требующим разрешения.
В облачном хранилище (например mail) файл дублируется и к его имени добавляется conflicted_copy.

Как реализовать это в веб?
То есть нужно сделать так, чтобы когда один менеджер открыл карту, она стала недоступна для второго.
А когда закрыл - доступна.

У меня есть варианты решения этой проблемы (свои "велосипеды"), но у каждого есть свои недостатки.
Как организовать работу с картами клиентов (БД) в веб? Как это делается в крупных проектах/системах, как это принято делать?

Answer 1

[Сергей Горностаев]

Почитайте про оптимистические блокировки.

Answer 2

[deepblack]

Как реализовать это в веб?
То есть нужно сделать так, чтобы когда один менеджер открыл карту, она стала недоступна для второго.
А когда закрыл - доступна.

Добавить в таблицу БД дополнительные поля:

locked BOOLEAN
locked_user_id BIGINT
locked_at TIMESTAMP

Выставлять признак блокировки на время редактирования, id пользователя который заблокировал запись, и время когда это (блокировка) произошло.
Для остальных на уровне приложения оставлять возможность работать с заблокированной записью в режиме чтения.
Добавить в админку возможность принудительно снять блокировку, а так-же периодически (по расписанию) снимать блокировку.

Comments

[V Sh.]

И будет постоянно что-то и где-то заблокировано. Уж луче перед самой записью в БД проверять, что запись не изменена и менять её, в ином случае сообщать пользователю, что "данные этой карточки были изменены ХХХХ сегодня в 15:49. Продолжить и затереть данные?".

[deepblack]

V Sh.,

Продолжить и затереть данные?"

Пользователи разделятся на два лагеря:
Одни будут затирать своими правками чужую работу.
Вторые будут панически бояться перезаписывать информацию, особенно когда им прилетит за это )

[Сергей Горностаев]

Андрей, в одном из моих проектов фронт при получении OPTIMISTIC_LOCK_ERROR, запрашивал текущую версию с бэка и показывал рядом с версией клиента. Клиент либо сводил вручную обе версии, либо отбрасывал одну из них.

[Евгений Иванов]

Андрей, принудительная/периодическое снятие блокировки - это решение "тупика", когда что то заглючило. Периодически снимать нельзя, ведь нет гарантии, что не произошла задержка получения данных, потеря пакета, краткосрочный разрыв соединения.

V Sh., ваш вариант решает часть проблемы. Да, теперь данные не "затрутся".
Но два менеджера откроют одну карту и будут уверены, что только они её редактируют.
А потом у одного менеджера окажется, что он делал работу зря, т.к. над картой поработал второй. А он и не знал, что кто то уже редактирует карту, вносит изменения.

[deepblack]

Евгений Иванов,

Периодически снимать нельзя, ведь нет гарантии, что не произошла задержка получения данных, потеря пакета, краткосрочный разрыв соединения.

отчасти да. Отчасти потому что если запись заблокирована продолжительное время то явно что-то пошло не так.
Я предложил один из возможных вариантов, решать как в вашем случае лучше сделать конечно же вам.