документооборот и доступ к файлам

[glibs]

Это, конечно, полумеры, но на всякий случай.

Для каждого типа документа можно указать разный каталог архива. С разными правами. Соответственно для каждого секретного вида документов отдельный тип документа настроить. Каталоги можно сделать "невидимыми" (приписать в конце имени $), чтобы меньше вредителей туда могло добраться.

[twilight]

А почему бы просто не хранить документы в базе?

[ivas]

Цитата:

Сообщение от twilight

А почему бы просто не хранить документы в базе?

их достаточно много > 50гб

[twilight]

Цитата:

Сообщение от ivas

их достаточно много > 50гб

А разве это влияет на производительность?
Почему бы не настроить хранение таблиц документооборота на отдельном сервере?

[ivas]

Цитата:

Сообщение от twilight

А разве это влияет на производительность?
Почему бы не настроить хранение таблиц документооборота на отдельном сервере?

мысль интересная надо её подумать

[glibs]

Цитата:

Сообщение от twilight

...
А почему бы просто не хранить документы в базе?
...
А разве это влияет на производительность?
...

Вопрос в количестве документов и количестве обращений к ним. А также в том, читаются они в основном или модифицируются.

Есть еще хороший вопрос про управление конфликтами на уровне доступа к файлам. И аспекты администрирования.

С т.з. производительности влияет. Это бесспорно. Вопрос только насколько существенно (ощутимо).

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

Даже если файлы хранятся большие, то таблицу с файлами (DocuValue) можно хранить на отдельном дисковом массиве, затолкав ее в отдельную файловую группу*, которую в свою очередь можно затолкать в отдельный физический файл, который можно хранить на отдельном дисковом массиве. Т.о. влияние хранения документов на "раздутие" БД, дефрагментацию файлов данных и скорость ввода-вывода на дисковом массиве, где хранятся основные данные, можно нивелировать.

Работа с документами врядли ощутимо нагрузит процессор сервера БД.

Работа с документами при интенсивной работе с большими по размеру файлами достаточно ощутимо загрузит сетевой интерфейс на сервере БД.

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

Последнее важно в связи с тем, то сервер БД сложно масштабировать.

Если вы что-то понимаете в задачах и процессах администрирования сервера БД, то... даже при условии хранения файлов на отдельном дисковом массиве БД (как единая сущность) будет пухнуть. А значит будет пухнуть архив БД. А это уже увеличит время на сервисные процедуры с БД (архивирование). Того же стоит ожидать и в случае, если БД будет восстанавливаться из архива при необходимости такого восстановления. А время — деньги, как известно.

Даже если учесть, что архивировать можно отдельные файлы данных, то процесс администрирования БД усложняется. И есть еще файл журнала транзакций БД. Насколько я знаю, его порезать на файловые группы не получится. А значит при вставке файла он будет расти, причем на основном массиве данных. И потом он будет архивироваться. А в случае сбоя — восстанавливаться. Но в любом случае вставка файла будет занимать ресурсы сервера БД.

А если, например, сервер БД сконфигурирован в режиме зеркалирования (горячий stand by), то пошло-поехало.

И наконец, стоит учитывать различия в функциональности документооборота, которые обусловлены тем или иным способом хранения файлов (скорее всего, это не полный список):
- При хранении файлов в БД файлы всегда передаются по сети. Если же файлы хранить на файловом сервере, то на удаленных инсталляциях есть возможность организации локальных файловых хранилищ для определенных видов файлов с доступом в рамках высокоскоростных локальных каналов.
- Мне пока на тестовой базе не удалось воспроизвести стабильную работу в режиме открыл файл, отредактировал, сохранил при работе с сохранением файлов в БД (я продолжу исследование данного вопроса и отпишу через некоторое время). Процесс сохранения измененных файлов при работе с файлами, которые хранятся в БД, не тривиален. В случае же если файлы хранятся на файловом сервере, то таких проблем не возникает. Если же файлы просто класть в БД... ну т.е. поправил — сохранил уже новую версию, то БД будет пухнуть. Хотя вариант имеет некотрые плюсы (версионность изменения файла хранится).
- Контроль совместный доступ к файлу. При хранении файла на файловом сервере совместным доступом будет управлять ОС файлового сервера. При открытии хранящегося в БД файла контроль совместного доступа не осуществляется.

Цитата:

Сообщение от twilight

...
Почему бы не настроить хранение таблиц документооборота на отдельном сервере?
...

А разве Аксапта поддерживает конфигурации, в которых есть несколько БД, расположенных на разных серверах?

Или что вы имеете в виду?

В общем, думайте сами, решайте сами, как говорилось... по-моему, в песне какой-то.

_____________
* Здесь и далее я буду оперировать терминологией и функциональными возможностями MS SQL. Просто я с ним работаю и в определенной степени его знаю. С Oracle я же наоборот практически не знаком. Однако я склонен считать, что все, что я написал, одинаково справедливо и для Oracle. Возможно, эксперты Oracle меня поправят, если это не так.

[ivas]

решили поступить так:
клиент будет "думать" что работает с БД, а AOS с файлами и передавать их в бинарном виде на клиента

[twilight]

Цитата:

Сообщение от glibs

Если вы что-то понимаете в задачах и процессах администрирования сервера БД, то... даже при условии хранения файлов на отдельном дисковом массиве БД (как единая сущность) будет пухнуть. А значит будет пухнуть архив БД. А это уже увеличит время на сервисные процедуры с БД (архивирование). Того же стоит ожидать и в случае, если БД будет восстанавливаться из архива при необходимости такого восстановления. А время — деньги, как известно.

С другой стороны, не нужно заниматься отдельно вопросом резервного копирования документов, они будут бэкапиться вместе со всей базой

Цитата:

Сообщение от glibs

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

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

Цитата:

Сообщение от glibs

- Контроль совместный доступ к файлу. При хранении файла на файловом сервере совместным доступом будет управлять ОС файлового сервера. При открытии хранящегося в БД файла контроль совместного доступа не осуществляется.

Да, с совместным доступом тяжело. С другой стороны, он не так уж часто требуется.

Цитата:

Сообщение от glibs

А разве Аксапта поддерживает конфигурации, в которых есть несколько БД, расположенных на разных серверах?

Или что вы имеете в виду?

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

А насчет производительности - пока не попробуешь, не узнаешь.

[glibs]

Цитата:

Сообщение от twilight

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

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

[ivas]

Цитата:

Сообщение от glibs

Это, конечно, полумеры, но на всякий случай.

Для каждого типа документа можно указать разный каталог архива. С разными правами. Соответственно для каждого секретного вида документов отдельный тип документа настроить. Каталоги можно сделать "невидимыми" (приписать в конце имени $), чтобы меньше вредителей туда могло добраться.

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

есть ещё вариант программно какимто образом устанавливать права в домене на файлы в зависимости от уровня доступа пользователей (у нас храниться в отдельной табличке для каждой записи в документообороте) в аксапте

[blokva]

Цитата:

Сообщение от ivas

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

есть ещё вариант программно какимто образом устанавливать права в домене на файлы в зависимости от уровня доступа пользователей (у нас храниться в отдельной табличке для каждой записи в документообороте) в аксапте

Если говорить про "тип" файла в документообороте, то это имеется ввиду его принадлежность к некой сущности аксапты, а не принадлежности к приложению.
Иными словами, Вам надо создать типы, к примеру: "Приказы директора", "Накладные приходные", "Наряды на работы" и т.д., и для каждолго типа выделить отдельный каталог на сервере. Тогда манипулируя правами в Аксапте , как обычными, так и на уровне записей, Вы сможете решить свою задачу.

зы: ИМХО glibs именно это и имел ввиду.

[ivas]

Цитата:

Сообщение от blokva

Если говорить про "тип" файла в документообороте, то это имеется ввиду его принадлежность к некой сущности аксапты, а не принадлежности к приложению.
Иными словами, Вам надо создать типы, к примеру: "Приказы директора", "Накладные приходные", "Наряды на работы" и т.д., и для каждолго типа выделить отдельный каталог на сервере. Тогда манипулируя правами в Аксапте , как обычными, так и на уровне записей, Вы сможете решить свою задачу.

зы: ИМХО glibs именно это и имел ввиду.

я так и понял...
просто к примеру если пользователь должен видеть один из документов типа "Приказы директора", то он увидит все документы с этим типом, а это не хорошо

[aidsua]

Цитата:

Сообщение от glibs

Это, конечно, полумеры, но на всякий случай.

Для каждого типа документа можно указать разный каталог архива. С разными правами. Соответственно для каждого секретного вида документов отдельный тип документа настроить. Каталоги можно сделать "невидимыми" (приписать в конце имени $), чтобы меньше вредителей туда могло добраться.

Любой чайник спокойно видит невидимые каталоги C$, D$, Admin$.. Более продвинутые пользуют для подобных целей Far Manager или что-то подобное..

Оптимальный вариант закрыть доступ на уровне домена к ресурсам.. имхо.