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 Пользователь может сохранить изменения если документ ранее был сохранен пользователем с полномочиями ниже или равными (см. рис).

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