|
Одновременное изменение документа
|
|||
---|---|---|---|
#18+
Есть БД, и 5-10 клиентов к нему подключенных. Как лучше сделать синхронизацию изменений одного и того же документа, если он редактируеться с двух разных клиентов в одно и то же время? Редактирование пакетное - при открытии запрашиваеться вся инфа по доку, закидываеться в контролы/кэшируеться. При нажатии на "сохранить" пишет в базу. Я вижу три пути: 1. Если кем то документ открыт на редактирование, другие могут открыть лишь на просмотр. То бишь при открытии проверять, открыт ли кем то еще, и если так, то дизаблить контролы. 2. При сохранении менять лишь то, что было изменено. Но тут надо будет проверять, что же изменилось. Данных много. Придеться проходить проходить по всем данным и сверять, что тоже не очень нравиться. Либо сделать систему, которая регистрирует изменения. Но насмотревшись на это всяких вордах(где внес изменение, потом исправил обратно, а при закрытии он все равно считает что ты что-то изменил) тоже не в восторге. 3. Если какой то параметр был изменен, обновлять его на других клиентах прямо в открытой форме. Тоже не очень нравиться решение(много сложностей с узнавание что что-то изменилось и обновлением этого). ... |
|||
:
Нравится:
Не нравится:
|
|||
20.05.2007, 19:15 |
|
Одновременное изменение документа
|
|||
---|---|---|---|
#18+
Собственно хочеться услышать ваши мнения, и как это сделано на других системах ... |
|||
:
Нравится:
Не нравится:
|
|||
20.05.2007, 19:17 |
|
Одновременное изменение документа
|
|||
---|---|---|---|
#18+
http://shara.by/download/~file=421c6b9bca81d3e7d7ce845f23381c05244799b7 или http://www.mirknig.com/2006/09/27/martin_fauler_arkhitektura_korporativnykh_programmnykh_prilozhenijj_ispravlennoe_izdanie.html ... |
|||
:
Нравится:
Не нравится:
|
|||
20.05.2007, 20:11 |
|
Одновременное изменение документа
|
|||
---|---|---|---|
#18+
Eugene7 Я вижу три пути: 1. Если кем то документ открыт на редактирование, другие могут открыть лишь на просмотр. То бишь при открытии проверять, открыт ли кем то еще, и если так, то дизаблить контролы. 2. При сохранении менять лишь то, что было изменено. Но тут надо будет проверять, что же изменилось. Данных много. Придеться проходить проходить по всем данным и сверять, что тоже не очень нравиться. Либо сделать систему, которая регистрирует изменения. Но насмотревшись на это всяких вордах(где внес изменение, потом исправил обратно, а при закрытии он все равно считает что ты что-то изменил) тоже не в восторге. 3. Если какой то параметр был изменен, обновлять его на других клиентах прямо в открытой форме. Тоже не очень нравиться решение(много сложностей с узнавание что что-то изменилось и обновлением этого). Пункт 2 желателен, и он никак не противоречит первому. Однозначно при открытии одним на редактирование другим давать только просмотр. Блокировка прикладного уровня реализуется элементарнейше независимо от типа сервера БД: одна таблица блокировок и две процедуры: заблокировать объект и снять блокировку. Пункт 3 в общем случае может оказаться неприемлемым бредом: принципиальных технических проблем в реализации подобного нет, но логических казусов может быть немеряно. Например один правит валюту документа, другой цену, один правит кол-во, другой ассотимент и т.д. Просмотр документа должен быть статическим. А то открыл документ, отвернулся - а за этот миг там поменялись отображаемые данные. Разумеется, если пока я смотрел документ, а другой в это время внес в него изменения и сохранил их, то если я захочу начать редактировать открытый на просмотр документ, система должна отследить, что были изменения, из-за которых отображенное у меня в форме уже неактуально и как-то отреагировать на это. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.05.2007, 00:04 |
|
Одновременное изменение документа
|
|||
---|---|---|---|
#18+
посмотрите как сделано в гугл догз. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.05.2007, 09:28 |
|
Одновременное изменение документа
|
|||
---|---|---|---|
#18+
Eugene7 пишет: > Есть БД, и 5-10 клиентов к нему подключенных. > Как лучше сделать синхронизацию изменений одного и того же документа, > если он редактируеться с двух разных клиентов в одно и то же время? Лучшая синхронизация - это ее отсутсвие. И не подумайте, что это шутка. На самом деле конфликты бывают редко, очень редко, и в основном люди просто договариваются друг с другом. > Редактирование пакетное - при открытии запрашиваеться вся инфа по доку, > закидываеться в контролы/кэшируеться. При нажатии на "сохранить" пишет в > базу. А вот это плохо. Если бы было непакетное, можно было бы просто оставить все на мелких атомарных консистентных транзакциях. Первое решение самое мудрое. и по-моему правильное. Posted via ActualForum NNTP Server 1.4 ... |
|||
:
Нравится:
Не нравится:
|
|||
21.05.2007, 10:19 |
|
Одновременное изменение документа
|
|||
---|---|---|---|
#18+
MasterZiv Eugene7 пишет: > Есть БД, и 5-10 клиентов к нему подключенных. > Как лучше сделать синхронизацию изменений одного и того же документа, > если он редактируеться с двух разных клиентов в одно и то же время? Лучшая синхронизация - это ее отсутсвие. И не подумайте, что это шутка. На самом деле конфликты бывают редко, очень редко, и в основном люди просто договариваются друг с другом. Только если они расположены в одном кабинете. В других же случаях, как показывает практика, конфликты могут происходить весьма часто. MasterZiv > Редактирование пакетное - при открытии запрашиваеться вся инфа по доку, > закидываеться в контролы/кэшируеться. При нажатии на "сохранить" пишет в > базу. А вот это плохо. Если бы было непакетное, можно было бы просто оставить все на мелких атомарных консистентных транзакциях. Почему плохо? Я бы сказал наоборот: это единственный правильный вариант. Или по крайней мере один из лучших. Пример сценария: открываю документ на редактирования, вношу разные изменения в разные его части. А потом по каким-либо причинам передумываю. В варианте пакетного изменения документа достаточно нажать кнопку "Отменить" или что-то типа того документ останется в исходном виде, как до начала редактирования. Как это сделать без пакетного изменения документа? Делать все в долгоиграющей транзакции? Ну-ну И потом, атомарные консистентные транзакции по изменению каждого атрибута могут привести к неконсистентности документа в целом на прикладном уровне ... |
|||
:
Нравится:
Не нравится:
|
|||
21.05.2007, 11:38 |
|
Одновременное изменение документа
|
|||
---|---|---|---|
#18+
Один документ состоит из нескольких строк с нескольких таблицах. Обычно поступают просто (на блокировочниках естесс-но). Перед тем как сохранять документ обновляют (или пытаются обновить) время модификации документа. Вариантов несколько - либо документ кем-то заблокирован, либо его кто-то уже изменил. Ну а дальше - уже и так понятно. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.05.2007, 13:06 |
|
Одновременное изменение документа
|
|||
---|---|---|---|
#18+
gardenmanОдин документ состоит из нескольких строк с нескольких таблицах. Обычно поступают просто (на блокировочниках естесс-но). Перед тем как сохранять документ обновляют (или пытаются обновить) время модификации документа. Вариантов несколько - либо документ кем-то заблокирован, либо его кто-то уже изменил. Ну а дальше - уже и так понятно. IMHO кривой вариант. Почему проверка делается перед сохранением документа а не перед началом редактирования? Это приведет к тому, что документ смогут начать редактировать одновременно несколько человек. Если процесс редактирования документа будет долгим, то можно при такой реализации получить кучу нецензурной брани в свой адрес. Ну простейшая же логика! зачем велосипеды придумывать? 1. Просматривать документ может любое количество человек одновременно 2. Открытая на просмотр форма документа не делает самопроизвольное изменение отображения. Просмотр статичен, что бы там ни делали другие с этим документом. 3. Перед началом редактирования документа форма делает следующее: а) проверяет, не поменялся ли документ с момента открытия на просмотр. Если поменялся, то пользователь об этом предупреждается и форма загружает свежую версию на просмотр. б) Пытается получить блокировку документа для редактирования. Если не получается - ругается, сообщая почему (кто и с какого момента сейчас правит этот документ) 4. При отмене редактирования форма просто убирает свою блокировку 5. При сохранении после успешного завершения форма просто убирает свою блокировку Блокировку прикладного уровня нет смысла завязывать на серверные блокировки. Делается элементарная таблица блокировок: что именно, кем, когда заблокированно. Делается процедура типа LockObject(тип объекта, код объекта), которая делает поиск соответствующей записи в блокировках. Если не находит, то создает новую. Если находит, то ругается, сообщая кем заблокировано. Соответственно делается еще процедура UnLockObject Плюс нужен механизм отработки аварийного завершения клиента для очистки зависших блокировок. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.05.2007, 13:33 |
|
Одновременное изменение документа
|
|||
---|---|---|---|
#18+
Александр ГoлдунНу простейшая же логика! зачем велосипеды придумывать? IMO вы описали [действительно распространенный и в общем неплохой] способ решить проблему, которая лежит не в области IT поддержки. Почему в один момент времени разные пользователи могут редактировать один документ ? Пускай бизнес хорошо подумает над этим казалось бы детским вопросом, а подумав выбирает из двух вариантов: 1 либо "кто последний - тот и прав". 2 либо храним историю изменения документа. На эти 2 варанта еще накладываются различные статусы документа. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.05.2007, 13:53 |
|
Одновременное изменение документа
|
|||
---|---|---|---|
#18+
> Я вижу три пути: Как это обычно бывает, правильный путь - четвертый. ;) Если конкурирующие версии документов - редкая ситуация, есть смысл реализовать первый из перечисленных вариантов. Если конкурирующие версии документов - обычная практика, есть смысл подумать над более общим решением, позволяющим не терять изменения, сделанные любым пользователем. Посмотрите, например, как работает Subversion. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.05.2007, 14:37 |
|
Одновременное изменение документа
|
|||
---|---|---|---|
#18+
Александр Гoлдун пишет: > А вот это плохо. Если бы было непакетное, можно было бы просто > оставить все на мелких атомарных консистентных транзакциях. > > > Почему плохо? Я бы сказал наоборот: это единственный правильный вариант. Я не люблю блокирование вообще. Я думаю что оно не нужно в 90% случаев. А так надо вообще блокировать документ эксклюзивно по хорошему, даже на чтение. Posted via ActualForum NNTP Server 1.4 ... |
|||
:
Нравится:
Не нравится:
|
|||
21.05.2007, 15:37 |
|
Одновременное изменение документа
|
|||
---|---|---|---|
#18+
Распространённые варианты. 1. Блокировка записи перед её изменением. Если запись уже изменена другим пользователем, система предлагает сделать повторный запрос, чтобы локальный буфер соответствовал сосотоянию БД, или отказаться от затеи. Если запись заблокирована другим пользователем, пользователь получает сообщение и может повторить попытку заблокировать запись, или отказаться от затеи. В данном случае блокировка может существовать длительное время, препятствуя работе других пользователей. С другой стороны при хорошей постановке документооборота за разработку документа в определённый период времени отвечает только один пользователь, поэтому такой режим не вызывает проблем. 2. Неблокирующее изменение записи. Запись изменяется в локальном буфере без блокировки, а затем сохраняется с проверкой на предмет изменения конкурирующим пользователем. Могут проверяться только ключевые поля (PK), PK и изменённые поля или все поля записи. Тут пользователь может проигнорировать чужие изменения, может отказаться от затеи. Если запись с данным PK не найдена, то считается что она удалена и изменить её нельзя. Такой подход хорош для Web приложений, когда системную блокировку установить проблематично, а программировать прикладные блокировки нецелесообразно. 3. Продвинутые системы управления версиями документов позволяют параллельно редактировать документы (их части), а затем сливать изменения. В простых случаях слияние может происходить автоматически. В случае конфликта, слияние делает пользователь системы. Если документы большие и требуют много времения на редактирование создать и удерживать системную блокировку практически невозможно. Как правило, пользователь с помощью разделяемой прикладной блокировки получает предупреждение, что ктото уже забрал документ на редактирование. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.05.2007, 16:52 |
|
Одновременное изменение документа
|
|||
---|---|---|---|
#18+
Ну что можно сказать по этому поводу: как весь мир делится на оптимистов и пессимистов, так и наше приложение может относиться к одной из этих сторон. Если это оптимистически настроенное приложение, то оно будет предполагать, что во время работы одного пользователя, с начала внесения им изменений и до их сохранения, другой пользователь не тронет те же данные, и, соответственно, оно не будет тратить ресурсы на установку блокировок. Естественно, надежды приложения на то, что другой пользователь ничего с редактируемыми нашим пользователем записями не сделал, могут не оправдаться, поэтому перед собственно сохранением изменений приложение должно проверить, а не изменились ли данные, пока наш пользователь их изменял, кем-то еще. Если вдруг такое случилось, приложение должно информировать нашего пользователя о том, что произошел "Уп-пс" и далее действовать по ситуации (в простейшем случае пользователя можно просто поставить перед фактом, что его изменения внесены не будут, потому что кто-то другой успел раньше; в более сложном пользователю можно показать чужие изменения и предложить выбрать, записать ли его изменения поверх чужих или нет; наконец, иногда приложение может обладать каким-то интеллектом и решить, как действовать, самостоятельно). Пессимистически настроенное приложение предполагает, что вероятность совместного редактирования велика, поэтому оно ставит блокировку сразу же, как только наш пользователь начнет редактирование, и снимает ее только после того, как изменения будут сохранены. Это гарантирует от набивания данных впустую, но зато в таких приложениях бывают проблемы длинных перекуров. Когда один пользователь начал работу с документом утром, потом его отвлекли, и далее до вечера он не вспоминал о том, что что-то по его вине заблокировано, а все прочие пользователи, которые тоже хотели внести изменения в те же записи, сильно ругались. Приложение, написанное подобным образом, должно либо предоставлять возможность администратору снять долгую блокировку, либо делать это автоматически, например, по превышении периода ожидания реакции пользователя. ________ Не дадим распространиться заразе политкорректности! ... |
|||
:
Нравится:
Не нравится:
|
|||
21.05.2007, 16:54 |
|
Одновременное изменение документа
|
|||
---|---|---|---|
#18+
guest_20040621 Если конкурирующие версии документов - редкая ситуация, есть смысл реализовать первый из перечисленных вариантов. Если конкурирующие версии документов - обычная практика, есть смысл подумать над более общим решением, позволяющим не терять изменения, сделанные любым пользователем. Посмотрите, например, как работает Subversion. Красиво звучит, но плохо представляю себе на практике. Вернемся с небес на землю, возьмем для примера банальнейший документ - накладную. Что такое конкурирующие версии накладной? Или может есть какие-то более удачные примеры? ... |
|||
:
Нравится:
Не нравится:
|
|||
21.05.2007, 17:28 |
|
Одновременное изменение документа
|
|||
---|---|---|---|
#18+
Александр Гoлдун пишет: > такое конкурирующие версии накладной? Или может есть какие-то более > удачные примеры? Вот и я говорю, что все равно всегда административными методами разруливается. т.е. абсолютно согласен с предыдущим оратарам. Небывает конкурирующих версий накладных. Есть ответственный чел, который ее делает. Если он уже ее не делает, то это его начальник. И т.п. Posted via ActualForum NNTP Server 1.4 ... |
|||
:
Нравится:
Не нравится:
|
|||
21.05.2007, 17:35 |
|
Одновременное изменение документа
|
|||
---|---|---|---|
#18+
> плохо представляю себе на практике Прайс-лист себе хорошо представляете? Представляете, как один сотрудник меняет розничные цены, второй - оптовые, третий - крупнооптовые? Договор представляете? Можете представить, что юрист пишет раздел "ответственность сторон", а менеджер вносит изменения в "условия поставки"? ... |
|||
:
Нравится:
Не нравится:
|
|||
21.05.2007, 18:04 |
|
Одновременное изменение документа
|
|||
---|---|---|---|
#18+
MasterZiv Александр Гoлдун пишет: > такое конкурирующие версии накладной? Или может есть какие-то более > удачные примеры? Вот и я говорю, что все равно всегда административными методами разруливается. т.е. абсолютно согласен с предыдущим оратарам. Небывает конкурирующих версий накладных. Есть ответственный чел, который ее делает. Если он уже ее не делает, то это его начальник. И т.п. Posted via ActualForum NNTP Server 1.4 Для документов я не вижу смысла в многоверсионности. Однако для разработки ПО, в этом может быть смысл. Например можно иметь и развивать несколько версий исходника. Оракл сейчас поддерживат версии 9i, 10g и разрабатывает 11g, таким образом могут быть актуальными минимум 3 версии исходников. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.05.2007, 18:09 |
|
Одновременное изменение документа
|
|||
---|---|---|---|
#18+
guest_20040621> плохо представляю себе на практике Прайс-лист себе хорошо представляете? Представляете, как один сотрудник меняет розничные цены, второй - оптовые, третий - крупнооптовые? Договор представляете? Можете представить, что юрист пишет раздел "ответственность сторон", а менеджер вносит изменения в "условия поставки"? А при чём тут разные версии? Это не версии, а части документа которые потом объединяются простой конкатенацией. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.05.2007, 18:10 |
|
Одновременное изменение документа
|
|||
---|---|---|---|
#18+
guest_20040621> плохо представляю себе на практике Прайс-лист себе хорошо представляете? Представляете, как один сотрудник меняет розничные цены, второй - оптовые, третий - крупнооптовые? Договор представляете? Можете представить, что юрист пишет раздел "ответственность сторон", а менеджер вносит изменения в "условия поставки"? Тут уже все разделено организационно. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.05.2007, 18:12 |
|
Одновременное изменение документа
|
|||
---|---|---|---|
#18+
> Тут уже все разделено организационно. Это пример простых документов, для которых коллективная работа имеет смысл. По поводу "все разделено организационно" - представьте, что изменения, скажем, в розничный прайс-лист вносятся не одним сотрудником, а несколькими. Причем, территориально рабочие места разнесены. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.05.2007, 18:31 |
|
Одновременное изменение документа
|
|||
---|---|---|---|
#18+
guest_20040621> Тут уже все разделено организационно. Это пример простых документов, для которых коллективная работа имеет смысл. По поводу "все разделено организационно" - представьте, что изменения, скажем, в розничный прайс-лист вносятся не одним сотрудником, а несколькими. Причем, территориально рабочие места разнесены. Да все равно, документы такого типа - композитные по сути своей. Вот хорошо было б если документ сам управлял собой. :) ... |
|||
:
Нравится:
Не нравится:
|
|||
21.05.2007, 18:44 |
|
Одновременное изменение документа
|
|||
---|---|---|---|
#18+
Сахават ЮсифовВот хорошо было б если документ сам управлял собой. :) Документ по сути своей объект пассивный. Для управления документом служат менеджеры транзакций, системы контроля версий и т.д. Какие в них правила заложены, так они документом и управляют. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.05.2007, 19:00 |
|
Одновременное изменение документа
|
|||
---|---|---|---|
#18+
> документы такого типа - композитные по сути своей А любые документы - они композитные. В том смысле, что могут быть представлены набором элементарных сущностей. Если доступ к ним (элементарным сущностям) может быть разделен административно - хорошо. Если нет - значит, нужны другие методы контроля. Для обычных файлов контроль версий - не фокус. Для СУБД - да, несколько геморройное занятие. Причем, на самом деле для практических задач его можно свести к регистрации изменений и приоритетам так, чтобы ручной работы было очень немного. > Вот хорошо было б если документ сам управлял собой В смысле "сам управлял собой"? ... |
|||
:
Нравится:
Не нравится:
|
|||
21.05.2007, 19:12 |
|
Одновременное изменение документа
|
|||
---|---|---|---|
#18+
Меня лично напрягают все эти СУБД. По мне бы - разделить ведение документа от его анализа. Каждый документ имел бы какие-то теги (авторы, допущенные, к каким частям, на какие действия и т.д.). Менеджер этого дока управлял бы доступностью (кто запрсил, с какими намерениями менял бы видимость или статус для изменений и т.д.), и параллельно выводил бы в отделнюю БД части для анализа на которые есть подписка и управлял бы синхронизацией этих частей. Так сумбурно. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.05.2007, 19:19 |
|
|
start [/forum/topic.php?fid=33&fpage=52&tid=1549078]: |
0ms |
get settings: |
11ms |
get forum list: |
17ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
36ms |
get topic data: |
12ms |
get forum data: |
2ms |
get page messages: |
186ms |
get tp. blocked users: |
2ms |
others: | 258ms |
total: | 530ms |
0 / 0 |