Eugene7
Я вижу три пути:
1. Если кем то документ открыт на редактирование, другие могут открыть лишь на просмотр. То бишь при открытии проверять, открыт ли кем то еще, и если так, то дизаблить контролы.
2. При сохранении менять лишь то, что было изменено. Но тут надо будет проверять, что же изменилось. Данных много. Придеться проходить проходить по всем данным и сверять, что тоже не очень нравиться. Либо сделать систему, которая регистрирует изменения. Но насмотревшись на это всяких вордах(где внес изменение, потом исправил обратно, а при закрытии он все равно считает что ты что-то изменил) тоже не в восторге.
3. Если какой то параметр был изменен, обновлять его на других клиентах прямо в открытой форме. Тоже не очень нравиться решение(много сложностей с узнавание что что-то изменилось и обновлением этого).
Пункт 2 желателен, и он никак не противоречит первому. Однозначно при открытии одним на редактирование другим давать только просмотр. Блокировка прикладного уровня реализуется элементарнейше независимо от типа сервера БД: одна таблица блокировок и две процедуры: заблокировать объект и снять блокировку.
Пункт 3 в общем случае может оказаться неприемлемым бредом: принципиальных технических проблем в реализации подобного нет, но логических казусов может быть немеряно. Например один правит валюту документа, другой цену, один правит кол-во, другой ассотимент и т.д. Просмотр документа должен быть статическим. А то открыл документ, отвернулся - а за этот миг там поменялись отображаемые данные. Разумеется, если пока я смотрел документ, а другой в это время внес в него изменения и сохранил их, то если я захочу начать редактировать открытый на просмотр документ, система должна отследить, что были изменения, из-за которых отображенное у меня в форме уже неактуально и как-то отреагировать на это.

MasterZiv
Eugene7 пишет:
> Есть БД, и 5-10 клиентов к нему подключенных.
> Как лучше сделать синхронизацию изменений одного и того же документа,
> если он редактируеться с двух разных клиентов в одно и то же время?

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

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

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

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

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

gardenmanОдин документ состоит из нескольких строк с нескольких таблицах. Обычно поступают просто (на блокировочниках естесс-но). Перед тем как сохранять документ обновляют (или пытаются обновить) время модификации документа. Вариантов несколько - либо документ кем-то заблокирован, либо его кто-то уже изменил. Ну а дальше - уже и так понятно.
IMHO кривой вариант. Почему проверка делается перед сохранением документа а не перед началом редактирования? Это приведет к тому, что документ смогут начать редактировать одновременно несколько человек. Если процесс редактирования документа будет долгим, то можно при такой реализации получить кучу нецензурной брани в свой адрес.

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

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

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

guest_20040621
Если конкурирующие версии документов - редкая ситуация, есть смысл реализовать первый из перечисленных вариантов. Если конкурирующие версии документов - обычная практика, есть смысл подумать над более общим решением, позволяющим не терять изменения, сделанные любым пользователем. Посмотрите, например, как работает Subversion.
Красиво звучит, но плохо представляю себе на практике. Вернемся с небес на землю, возьмем для примера банальнейший документ - накладную. Что такое конкурирующие версии накладной? Или может есть какие-то более удачные примеры?

guest_20040621> плохо представляю себе на практике

Прайс-лист себе хорошо представляете?

Более чем хорошо И представляю, и имел честь проектировать, разрабатывать и внедрять.
guest_20040621
Представляете, как один сотрудник меняет розничные цены, второй - оптовые, третий - крупнооптовые?

Рассматривал как 3 разных прайса.
guest_20040621
Договор представляете? Можете представить, что юрист пишет раздел "ответственность сторон", а менеджер вносит изменения в "условия поставки"?
Ага, а еще бывают приложения к договору и т.п. Здесь все проще и проблемы, которую можно было бы решить версионностью, нет. Как тут уже отметили, явный пример композитного документа. Можно разделить организационным путем, можно вообще на уровне интерфейса на разных рабочих местах сделать разные формы работы с документом.
guest_20040621
Это пример простых документов, для которых коллективная работа имеет смысл. По поводу "все разделено организационно" - представьте, что изменения, скажем, в розничный прайс-лист вносятся не одним сотрудником, а несколькими.

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

Верно подмечено, сам хотел привести подобный пример. Если территориальное разнесение подразумевает, тем не менее, онлайновую работу с единой БД, тогда не вижу разницы. А вот в случае распределенных БД, да еще и с off-line репликацией - тогда да, есть такая проблема. В данном случае не получается элегантно сделать удобный механизм блокировок, как я описал ранее. Вариантов в таком случае мало:
1. Предложенный вами вариант с версионностью. Достаточно нетривиален в реализации и регламентах отработки конфликтов
2. Организационное решение. Ну, тут все понятно. Четко разделяем области ответственности, например по набору реквизитов документа или же по статусам.
3. Все таки механизм блокировок. Но оправданность такого механизма для офф-лайн случая тяжело придумать. Реализовать то можно, но если расписание обмена скажем минут 20, то получить подтверждение о возможности редактирования можно будет за 20-40 минут.

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

mcureenab Александр ГoлдунВ крайнем случае скажет-позвонит-напишет коллеге, на котором блокировка, поинтересовавшись надолго ли

Другой вариант.

-- Ааааа!!! Система не работает, сделать ничего нельзя, во всём виноваты программисты!!!
Это уже вопрос не технический, а кадровый. Надо уметь воспитывать пользователей :)

Александр Гoлдун mcureenab
Другой вариант.

-- Ааааа!!! Система не работает, сделать ничего нельзя, во всём виноваты программисты!!!
Это уже вопрос не технический, а кадровый. Надо уметь воспитывать пользователей :)
Хотя, если пользователю выскакивает маловнятное сообщение об ошибке, тогда он прав - виноваты программисты.

guest_20040621> Ага, а еще бывают приложения к договору и т.п. Здесь все проще и проблемы, которую можно было
> бы решить версионностью, нет.

Еще как есть. Простой пример: тот же договор с приложениями. Часть приложений - стандартные файлы, лежат себе где-нибудь на ftp, часть приложений - лежат в системе контроля версий. Часть договора - в базе данных. Как Вы это все вместе собираетесь разгребать? Откуда версионность? - любой серьезный договор. Он согласовывается не раз, не два и не три.
Вопрос целесообразности ведения этих версий БД. В системах документооборота возможно это актуально. Но чаще всего подобного рода работа ведется либо за пределами системы, а в базе уже фиксируется конечный вариант, либо все-таки все стадии проходят через БД, но опять таки, остается только конечный вариант. Разумеется, возможны частные случаи, когда в системах подобная работа отражается с максимальной детализацией, но мне не знакомы ни такие системы, ни примеры, где такое необходимо. Может быть потому что не приходилось очень плотно заниматься проблемами серьезных юридических отделов.

Кроме договоров примеры есть?

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

iscrafm1.Блокировка для того, чтобы другой пользователь не мог изменить документ - не более чем иллюзия, придуманная для того, чтобы каким-то образом обосновать неспособность разрулить ситуацию по полномочиям.

Да, иногда нет возможности полностью исключить возможность одновременной правки организационным путем или полномочиями. Ни разу не приходилось сталкиваться с документооборотом хотя бы в тысячи однотипных документов в день, когда большое число исполнителей одновременно обрабатывают общий пакет документов, внутри которого сделать жесткое разделение на все времена практически нереально?
iscrafm
Если более одного пользователя имеют полномочия на редактирование документа, то блокируй-не блокируй... в итоге документ будет в том виде, который ему придаст пользователь, редактировавший его последним. В случае с блокировкой ему просто придется подождать, чтобы сделать задуманное.

Мы о чем рассуждаем? Об уменьшении вероятности ошибок из-за коллизий или о предотвращении умышленного вредительского саботажа, типа "а я все равно испорчу, что там коллега наваял"? Если второе, то комплекс мер для предотвращения подобного выглядит совершенно по другому.
iscrafm
Т.е., кроме ненужных пухлых алгоритмов этот метод ничего не дает.

Пухлых? Реализация механизма в разы проще, чем описание на словах. А использование в документах - так вообще один вызов функции перед началом редактирования и один вызов по завершении. Где пухлость?
iscrafm
2. Разруливание по полномочиям исключает всякие коллизии.

как уже сказал, возможно далеко не всегда
iscrafm
3. Вполне достаточно действий по принципу "кто последний, тот и прав",

Недостаточно
iscrafm
а если и нужно поддерживать чистоту рядов то:
3.1 Пользователь может сохранять изменения только в документе, автором которого он же и является

еще раз говорю, это приемлемо только для простых орг структур с ограниченным числом исполнителей. Типа один продажник, один закупщик, один кладовщик и т.п. Реальность же часто бывает неизмеримо сложнее.
iscrafm
3.2 Пользователь может сохранить изменения если документ ранее был сохранен пользователем с полномочиями ниже или равными (см. рис).

Неприемлено для документов, имеющих сложный жизненный путь.

iscrafm Александр Гoлдун
Неприемлено для документов, имеющих сложный жизненный путь.
был бы признателен за расшифровку.. что Вы понимаете под "сложным жизненным путем" документа
Да любой документ, имеющий больше статусов, нежели проведен-непроведен, когда в разных состояниях с ним могут работать разные люди. Какие-нибудь заявки, требующие согласования, утверждения и т.п. В таком варианте пункт:

3.2 Пользователь может сохранить изменения если документ ранее был сохранен пользователем с полномочиями ниже или равными (см. рис).

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