powered by simpleCommunicator - 2.0.50     © 2025 Programmizd 02
Форумы / Разработка информационных систем [игнор отключен] [закрыт для гостей] / Одновременное изменение документа
25 сообщений из 61, страница 1 из 3
Одновременное изменение документа
    #34538298
Eugene7
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Есть БД, и 5-10 клиентов к нему подключенных.
Как лучше сделать синхронизацию изменений одного и того же документа, если он редактируеться с двух разных клиентов в одно и то же время?
Редактирование пакетное - при открытии запрашиваеться вся инфа по доку, закидываеться в контролы/кэшируеться. При нажатии на "сохранить" пишет в базу.
Я вижу три пути:
1. Если кем то документ открыт на редактирование, другие могут открыть лишь на просмотр. То бишь при открытии проверять, открыт ли кем то еще, и если так, то дизаблить контролы.
2. При сохранении менять лишь то, что было изменено. Но тут надо будет проверять, что же изменилось. Данных много. Придеться проходить проходить по всем данным и сверять, что тоже не очень нравиться. Либо сделать систему, которая регистрирует изменения. Но насмотревшись на это всяких вордах(где внес изменение, потом исправил обратно, а при закрытии он все равно считает что ты что-то изменил) тоже не в восторге.
3. Если какой то параметр был изменен, обновлять его на других клиентах прямо в открытой форме. Тоже не очень нравиться решение(много сложностей с узнавание что что-то изменилось и обновлением этого).
...
Рейтинг: 0 / 0
Одновременное изменение документа
    #34538301
Eugene7
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Собственно хочеться услышать ваши мнения, и как это сделано на других системах
...
Рейтинг: 0 / 0
Одновременное изменение документа
    #34538349
UrryMcA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
http://shara.by/download/~file=421c6b9bca81d3e7d7ce845f23381c05244799b7
или http://www.mirknig.com/2006/09/27/martin_fauler_arkhitektura_korporativnykh_programmnykh_prilozhenijj_ispravlennoe_izdanie.html
...
Рейтинг: 0 / 0
Одновременное изменение документа
    #34538514
Фотография Александр Гoлдун
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Eugene7
Я вижу три пути:
1. Если кем то документ открыт на редактирование, другие могут открыть лишь на просмотр. То бишь при открытии проверять, открыт ли кем то еще, и если так, то дизаблить контролы.
2. При сохранении менять лишь то, что было изменено. Но тут надо будет проверять, что же изменилось. Данных много. Придеться проходить проходить по всем данным и сверять, что тоже не очень нравиться. Либо сделать систему, которая регистрирует изменения. Но насмотревшись на это всяких вордах(где внес изменение, потом исправил обратно, а при закрытии он все равно считает что ты что-то изменил) тоже не в восторге.
3. Если какой то параметр был изменен, обновлять его на других клиентах прямо в открытой форме. Тоже не очень нравиться решение(много сложностей с узнавание что что-то изменилось и обновлением этого).
Пункт 2 желателен, и он никак не противоречит первому. Однозначно при открытии одним на редактирование другим давать только просмотр. Блокировка прикладного уровня реализуется элементарнейше независимо от типа сервера БД: одна таблица блокировок и две процедуры: заблокировать объект и снять блокировку.
Пункт 3 в общем случае может оказаться неприемлемым бредом: принципиальных технических проблем в реализации подобного нет, но логических казусов может быть немеряно. Например один правит валюту документа, другой цену, один правит кол-во, другой ассотимент и т.д. Просмотр документа должен быть статическим. А то открыл документ, отвернулся - а за этот миг там поменялись отображаемые данные. Разумеется, если пока я смотрел документ, а другой в это время внес в него изменения и сохранил их, то если я захочу начать редактировать открытый на просмотр документ, система должна отследить, что были изменения, из-за которых отображенное у меня в форме уже неактуально и как-то отреагировать на это.
...
Рейтинг: 0 / 0
Одновременное изменение документа
    #34538761
Xoxerix
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
посмотрите как сделано в гугл догз.
...
Рейтинг: 0 / 0
Одновременное изменение документа
    #34538871
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Eugene7 пишет:
> Есть БД, и 5-10 клиентов к нему подключенных.
> Как лучше сделать синхронизацию изменений одного и того же документа,
> если он редактируеться с двух разных клиентов в одно и то же время?

Лучшая синхронизация - это ее отсутсвие. И не подумайте, что это шутка.
На самом деле конфликты бывают редко, очень редко, и в основном
люди просто договариваются друг с другом.

> Редактирование пакетное - при открытии запрашиваеться вся инфа по доку,
> закидываеться в контролы/кэшируеться. При нажатии на "сохранить" пишет в
> базу.

А вот это плохо. Если бы было непакетное, можно было бы просто
оставить все на мелких атомарных консистентных транзакциях.

Первое решение самое мудрое. и по-моему правильное.
Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
Одновременное изменение документа
    #34539079
Фотография Александр Гoлдун
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MasterZiv
Eugene7 пишет:
> Есть БД, и 5-10 клиентов к нему подключенных.
> Как лучше сделать синхронизацию изменений одного и того же документа,
> если он редактируеться с двух разных клиентов в одно и то же время?

Лучшая синхронизация - это ее отсутсвие. И не подумайте, что это шутка.
На самом деле конфликты бывают редко, очень редко, и в основном
люди просто договариваются друг с другом.

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

MasterZiv
> Редактирование пакетное - при открытии запрашиваеться вся инфа по доку,
> закидываеться в контролы/кэшируеться. При нажатии на "сохранить" пишет в
> базу.

А вот это плохо. Если бы было непакетное, можно было бы просто
оставить все на мелких атомарных консистентных транзакциях.

Почему плохо? Я бы сказал наоборот: это единственный правильный вариант. Или по крайней мере один из лучших.
Пример сценария: открываю документ на редактирования, вношу разные изменения в разные его части. А потом по каким-либо причинам передумываю. В варианте пакетного изменения документа достаточно нажать кнопку "Отменить" или что-то типа того документ останется в исходном виде, как до начала редактирования. Как это сделать без пакетного изменения документа? Делать все в долгоиграющей транзакции? Ну-ну
И потом, атомарные консистентные транзакции по изменению каждого атрибута могут привести к неконсистентности документа в целом на прикладном уровне
...
Рейтинг: 0 / 0
Одновременное изменение документа
    #34539362
gardenman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Один документ состоит из нескольких строк с нескольких таблицах. Обычно поступают просто (на блокировочниках естесс-но). Перед тем как сохранять документ обновляют (или пытаются обновить) время модификации документа. Вариантов несколько - либо документ кем-то заблокирован, либо его кто-то уже изменил. Ну а дальше - уже и так понятно.
...
Рейтинг: 0 / 0
Одновременное изменение документа
    #34539451
Фотография Александр Гoлдун
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
gardenmanОдин документ состоит из нескольких строк с нескольких таблицах. Обычно поступают просто (на блокировочниках естесс-но). Перед тем как сохранять документ обновляют (или пытаются обновить) время модификации документа. Вариантов несколько - либо документ кем-то заблокирован, либо его кто-то уже изменил. Ну а дальше - уже и так понятно.
IMHO кривой вариант. Почему проверка делается перед сохранением документа а не перед началом редактирования? Это приведет к тому, что документ смогут начать редактировать одновременно несколько человек. Если процесс редактирования документа будет долгим, то можно при такой реализации получить кучу нецензурной брани в свой адрес.

Ну простейшая же логика! зачем велосипеды придумывать?
1. Просматривать документ может любое количество человек одновременно
2. Открытая на просмотр форма документа не делает самопроизвольное изменение отображения. Просмотр статичен, что бы там ни делали другие с этим документом.
3. Перед началом редактирования документа форма делает следующее:
а) проверяет, не поменялся ли документ с момента открытия на просмотр. Если поменялся, то пользователь об этом предупреждается и форма загружает свежую версию на просмотр.
б) Пытается получить блокировку документа для редактирования. Если не получается - ругается, сообщая почему (кто и с какого момента сейчас правит этот документ)
4. При отмене редактирования форма просто убирает свою блокировку
5. При сохранении после успешного завершения форма просто убирает свою блокировку

Блокировку прикладного уровня нет смысла завязывать на серверные блокировки. Делается элементарная таблица блокировок: что именно, кем, когда заблокированно.
Делается процедура типа LockObject(тип объекта, код объекта), которая делает поиск соответствующей записи в блокировках. Если не находит, то создает новую. Если находит, то ругается, сообщая кем заблокировано.
Соответственно делается еще процедура UnLockObject

Плюс нужен механизм отработки аварийного завершения клиента для очистки зависших блокировок.
...
Рейтинг: 0 / 0
Одновременное изменение документа
    #34539538
Alexey Kudinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Александр ГoлдунНу простейшая же логика! зачем велосипеды придумывать?
IMO вы описали [действительно распространенный и в общем неплохой] способ решить проблему, которая лежит не в области IT поддержки. Почему в один момент времени разные пользователи могут редактировать один документ ? Пускай бизнес хорошо подумает над этим казалось бы детским вопросом, а подумав выбирает из двух вариантов:

1 либо "кто последний - тот и прав".
2 либо храним историю изменения документа.

На эти 2 варанта еще накладываются различные статусы документа.
...
Рейтинг: 0 / 0
Одновременное изменение документа
    #34539713
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
> Я вижу три пути:

Как это обычно бывает, правильный путь - четвертый. ;)

Если конкурирующие версии документов - редкая ситуация, есть смысл реализовать первый из перечисленных вариантов. Если конкурирующие версии документов - обычная практика, есть смысл подумать над более общим решением, позволяющим не терять изменения, сделанные любым пользователем. Посмотрите, например, как работает Subversion.
...
Рейтинг: 0 / 0
Одновременное изменение документа
    #34539933
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Александр Гoлдун пишет:

> А вот это плохо. Если бы было непакетное, можно было бы просто
> оставить все на мелких атомарных консистентных транзакциях.
>
>
> Почему плохо? Я бы сказал наоборот: это единственный правильный вариант.

Я не люблю блокирование вообще. Я думаю что оно не нужно в 90% случаев.
А так надо вообще блокировать документ эксклюзивно по хорошему,
даже на чтение.
Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
Одновременное изменение документа
    #34540208
mcureenab
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Распространённые варианты.

1. Блокировка записи перед её изменением. Если запись уже изменена другим пользователем, система предлагает сделать повторный запрос, чтобы локальный буфер соответствовал сосотоянию БД, или отказаться от затеи. Если запись заблокирована другим пользователем, пользователь получает сообщение и может повторить попытку заблокировать запись, или отказаться от затеи.

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

2. Неблокирующее изменение записи. Запись изменяется в локальном буфере без блокировки, а затем сохраняется с проверкой на предмет изменения конкурирующим пользователем. Могут проверяться только ключевые поля (PK), PK и изменённые поля или все поля записи. Тут пользователь может проигнорировать чужие изменения, может отказаться от затеи. Если запись с данным PK не найдена, то считается что она удалена и изменить её нельзя.

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

3. Продвинутые системы управления версиями документов позволяют параллельно редактировать документы (их части), а затем сливать изменения. В простых случаях слияние может происходить автоматически. В случае конфликта, слияние делает пользователь системы.

Если документы большие и требуют много времения на редактирование создать и удерживать системную блокировку практически невозможно. Как правило, пользователь с помощью разделяемой прикладной блокировки получает предупреждение, что ктото уже забрал документ на редактирование.
...
Рейтинг: 0 / 0
Одновременное изменение документа
    #34540213
Urri
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ну что можно сказать по этому поводу: как весь мир делится на оптимистов и пессимистов, так и наше приложение может относиться к одной из этих сторон.

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

Пессимистически настроенное приложение предполагает, что вероятность совместного редактирования велика, поэтому оно ставит блокировку сразу же, как только наш пользователь начнет редактирование, и снимает ее только после того, как изменения будут сохранены. Это гарантирует от набивания данных впустую, но зато в таких приложениях бывают проблемы длинных перекуров. Когда один пользователь начал работу с документом утром, потом его отвлекли, и далее до вечера он не вспоминал о том, что что-то по его вине заблокировано, а все прочие пользователи, которые тоже хотели внести изменения в те же записи, сильно ругались.
Приложение, написанное подобным образом, должно либо предоставлять возможность администратору снять долгую блокировку, либо делать это автоматически, например, по превышении периода ожидания реакции пользователя.
________
Не дадим распространиться заразе политкорректности!
...
Рейтинг: 0 / 0
Одновременное изменение документа
    #34540293
Фотография Александр Гoлдун
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
guest_20040621
Если конкурирующие версии документов - редкая ситуация, есть смысл реализовать первый из перечисленных вариантов. Если конкурирующие версии документов - обычная практика, есть смысл подумать над более общим решением, позволяющим не терять изменения, сделанные любым пользователем. Посмотрите, например, как работает Subversion.
Красиво звучит, но плохо представляю себе на практике. Вернемся с небес на землю, возьмем для примера банальнейший документ - накладную. Что такое конкурирующие версии накладной? Или может есть какие-то более удачные примеры?
...
Рейтинг: 0 / 0
Одновременное изменение документа
    #34540311
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Александр Гoлдун пишет:

> такое конкурирующие версии накладной? Или может есть какие-то более
> удачные примеры?

Вот и я говорю, что все равно всегда административными методами разруливается.
т.е. абсолютно согласен с предыдущим оратарам. Небывает конкурирующих версий
накладных. Есть ответственный чел, который ее делает. Если он уже ее не делает,
то это его начальник. И т.п.
Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
Одновременное изменение документа
    #34540379
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
> плохо представляю себе на практике

Прайс-лист себе хорошо представляете? Представляете, как один сотрудник меняет розничные цены, второй - оптовые, третий - крупнооптовые? Договор представляете? Можете представить, что юрист пишет раздел "ответственность сторон", а менеджер вносит изменения в "условия поставки"?
...
Рейтинг: 0 / 0
Одновременное изменение документа
    #34540399
mcureenab
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MasterZiv
Александр Гoлдун пишет:

> такое конкурирующие версии накладной? Или может есть какие-то более
> удачные примеры?

Вот и я говорю, что все равно всегда административными методами разруливается.
т.е. абсолютно согласен с предыдущим оратарам. Небывает конкурирующих версий
накладных. Есть ответственный чел, который ее делает. Если он уже ее не делает,
то это его начальник. И т.п.
Posted via ActualForum NNTP Server 1.4

Для документов я не вижу смысла в многоверсионности. Однако для разработки ПО, в этом может быть смысл. Например можно иметь и развивать несколько версий исходника. Оракл сейчас поддерживат версии 9i, 10g и разрабатывает 11g, таким образом могут быть актуальными минимум 3 версии исходников.
...
Рейтинг: 0 / 0
Одновременное изменение документа
    #34540408
mcureenab
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
guest_20040621> плохо представляю себе на практике

Прайс-лист себе хорошо представляете? Представляете, как один сотрудник меняет розничные цены, второй - оптовые, третий - крупнооптовые? Договор представляете? Можете представить, что юрист пишет раздел "ответственность сторон", а менеджер вносит изменения в "условия поставки"?

А при чём тут разные версии? Это не версии, а части документа которые потом объединяются простой конкатенацией.
...
Рейтинг: 0 / 0
Одновременное изменение документа
    #34540415
Сахават Юсифов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
guest_20040621> плохо представляю себе на практике

Прайс-лист себе хорошо представляете? Представляете, как один сотрудник меняет розничные цены, второй - оптовые, третий - крупнооптовые? Договор представляете? Можете представить, что юрист пишет раздел "ответственность сторон", а менеджер вносит изменения в "условия поставки"?

Тут уже все разделено организационно.
...
Рейтинг: 0 / 0
Одновременное изменение документа
    #34540496
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
> Тут уже все разделено организационно.

Это пример простых документов, для которых коллективная работа имеет смысл. По поводу "все разделено организационно" - представьте, что изменения, скажем, в розничный прайс-лист вносятся не одним сотрудником, а несколькими. Причем, территориально рабочие места разнесены.
...
Рейтинг: 0 / 0
Одновременное изменение документа
    #34540532
Сахават Юсифов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
guest_20040621> Тут уже все разделено организационно.

Это пример простых документов, для которых коллективная работа имеет смысл. По поводу "все разделено организационно" - представьте, что изменения, скажем, в розничный прайс-лист вносятся не одним сотрудником, а несколькими. Причем, территориально рабочие места разнесены.
Да все равно, документы такого типа - композитные по сути своей.

Вот хорошо было б если документ сам управлял собой. :)
...
Рейтинг: 0 / 0
Одновременное изменение документа
    #34540574
mcureenab
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Сахават ЮсифовВот хорошо было б если документ сам управлял собой. :)

Документ по сути своей объект пассивный. Для управления документом служат менеджеры транзакций, системы контроля версий и т.д. Какие в них правила заложены, так они документом и управляют.
...
Рейтинг: 0 / 0
Одновременное изменение документа
    #34540611
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
> документы такого типа - композитные по сути своей

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

Для обычных файлов контроль версий - не фокус. Для СУБД - да, несколько геморройное занятие. Причем, на самом деле для практических задач его можно свести к регистрации изменений и приоритетам так, чтобы ручной работы было очень немного.

> Вот хорошо было б если документ сам управлял собой

В смысле "сам управлял собой"?
...
Рейтинг: 0 / 0
Одновременное изменение документа
    #34540628
Сахават Юсифов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Меня лично напрягают все эти СУБД.
По мне бы - разделить ведение документа от его анализа.
Каждый документ имел бы какие-то теги (авторы, допущенные, к каким частям, на какие действия и т.д.). Менеджер этого дока управлял бы доступностью (кто запрсил, с какими намерениями менял бы видимость или статус для изменений и т.д.), и параллельно выводил бы в отделнюю БД части для анализа на которые есть подписка и управлял бы синхронизацией этих частей.
Так сумбурно.
...
Рейтинг: 0 / 0
25 сообщений из 61, страница 1 из 3
Форумы / Разработка информационных систем [игнор отключен] [закрыт для гостей] / Одновременное изменение документа
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]