Оценка эффективности различных топологий распределенных архивов документов

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

А какие еще есть варианты для территориально разнесенных филиалов, разграниченными тонкими каналами связи?
Мы все привыкли думать, что хранилище должно быть единым и централизованным, а передача электронных документов в рамках корпоративной сети должна быть в виде ссылки. Однако это только на логическом уровне.
Документы – это не записи в базе данных: их так просто не реплицировать, особенно двунаправлено.
В данном случае, под хранилищем понимается весь упорядоченный объем неструктурированной информации компании, с которым работают пользователи, выполняя операции чтения, согласования, правки и т.д.
Тогда для распределенных организаций хранилищу, скорее всего, придется быть тоже распределенным на физическом уровне, предоставляя доступ к документам разных узлов с разной степенью оперативности.
Репликацией проблему решить весьма трудно (если вообще возможно), ибо встает речь о разрешение конфликтных ситуаций, например, при одновременном выписывании одного и того же документа разными пользователями на разных узлах распределенной системы управления документами (СУД). Ведь узлы СУД не обязаны находиться перманентно в онлайне, по причине возможных сбоев в сети.
С однонаправленной репликацией все обстоит проще: документы чужих узлов распределенной СУД всегда остаются хранятся только в режиме доступа на чтение.

Кстати, Александр, Вы как специалист по электронным архивам на базе Lotus, решаете как-нибудь эту проблему в своих решениях?

В продвинутых IDMS эта проблема, решается, например, путем создания промежуточного локального хранилища (кэш), в которое складываются копии документов с удаленны узлов, запрашиваемые через локальный узел. Это возможно только при условии, что элементы распределенного хранилища (т.н. удаленные библиотеки документов) находятся в постоянном онлайновом доступе для узла СУД, к которому подключены пользователи. Пользователь, найдя документ в удаленной библиотеке, запрашивает его. (В продвинутых СУД, поиск, как правило, выполняется прозрачным образом по всем доступным библиотекам, с использованием удаленной индексной информации, а результат консолидируется на узле, с которым работает пользователь). При этом происходит проверка наличия документа с той же датой в кэше. Если есть - документ открывается с той же скоростью, что и документы с локального хранилища, если нет – придется системе сначала его загрузить в кэш.
Кэш инвентаризируется по расписанию.

Хотя мне больше всего нравится более просто вариант распределенного хранилища: с центральной СУБД постоянно доступной для всех филиальных СУД. Тогда все метаданные библиотеки документов и реквизиты документов, хранятся в одной базе данных. А документы каждого филиала, сохраняются на своем, отдельном, файловом сервере, доступного из любого другого филиала (разумеется, с разной скоростью).

В российской действительности экономия на линиях связи бывает вынужденной.

Реально вопрос следует разделить на два:
1) какова должна быть топология хранилища с точки зрения пользователя;
2) какова должна быть топология хранилища с точки зрения физического расположения мест хранения конкретных документов.

Смешивать эти два вопроса любят, например, бывшие (или настоящие) программисты или админы SQL-серверов. Потом получается слабо модернизируемая система, привязанная к конкретной СУБД.

Высказывания о проблематичности репликации сущностей более сложных, чем "запись в базе", а также о жутких случаях "одновременного выписывания одного и того же документа в разных подразделениях" говорят о том, что товарищ не знаком с предметной областью ;)

Достаточно гибкое решение с распределенным хранением и репликацией документов реализовано в FlyDoc. При желании можно "отсылать" документ в другой филиал(ы) компании. Вспомогательные справочники реплицируются автоматически в необходимом объеме, вместе с вложениями, update-конфликты разрешаются по принципу "прав последний отредактировавший". Другие правила (например, "всегда прав головной офис") можно реализовать организационно, запретив на местах менять конкретные справочники. Одновременное редактирование документа двумя пользователями в одной локальной сети приведет к показу различий текущей и сохраненной версии и предложению сохранить свой вариант или загрузить чужие данные.

Дополнительная информация - на сайте http://www.flydoc.ru

Добрый день. я хотела бы узнать возможно ли в системе DOCFLOW ведение РКК документов, ведение номенклатуры дел,сканирование документов и регистрация документов из электронной почты?