Здравствуйте.

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

Как лучше организовать такое хранение и сопоставление? Через внешние источники данных?

ЗЫ: пользователю на выбор для каждого контрагента будет даваться право где хранить данные: в отдельной базе данных или на компьютере (в папке).

Беги оттуда

Почему? Объем документов большой, поэтому, есть такая идея.

Делай вьюшку на другую базу. Только с точки зрения лицензионной политики 1С это айяйяй )

читай про интеграцию документооборота...

например в УХ это реализовано...

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

(0)Зачем всё это?

Зачем всё это? Кто платит за весь этот банкет?

(0) В этой отдельной базе делаешь вебсервис, к которому будет обращаться твоя основная база. Вебсервис принимает файлы на хранение и выдает файлы по запросу. В основной базе на некий период лучше кешировать.
(6) Да мало ли. Например, чтобы обновление конфигурации основной базы не зависело от количество картинок в базе. Требования к резерезвному копированию данных и картинок этих могут быть разными. Много вариантов.

Да еще лучше так.
Пользователь прикрепляет файлы к объектам БД и они хранятся, как принято, в справочнике.
Потом регламентное раз в Х часов проходит по справочнику и:
1. Передает через вебсервис в отдельную базу всё, чего в отдельной базе нет, и то, что изменилось с последней передачи
2. Удаляет все файлы, срок хранения которых во временном кэше истек.
3. Когда польователь обращается к файлу, сначала поиск производится в локальном кэше и, если там пусто, делается запрос к вебсервису.

(0) Документы проще, удобнее и дешевле хранить на файловой системе.
Файловая система - самая лучшая БД для документов.

Файловая это конечно проще всех. Но как производить поиск в нем? Например, файлы будут прикрепляться не к договору,а документам. Как тогда найти на сервере файлы именно этого документа?

УХ в интеграции документоборота - это что?

(10) с точки зрения пользователя отличий никаких, просто вместо реквизита с типом ХЗ у тебя строка с адресом файла на диске.

(8) Клёвый мопед, приведи хоть один плюс по сравнению с хранением на диске. Интеграцию с третьими системами не рассматриваем.

(10) Точно так же как и в базе.
У вас же в базе будет хранится  путь к этому документу.

Допустим они хранятся у вас в базе - вы каким то образом найдете тот документ который вам нужен и прочитаете его из базы.
Если они будут храниться в ФС - вы точно так же найдете документ который вам нужен и прочитаете из базы, только не сам документ, а путь к нему.

Вот и вся разница в поиске.

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

А вот база 1с, и база SQL не самые оптимальные вещи для этого.
В итоге если вы храните файлы в ФС у вас не распухает база, меньше требования к железу, удобней все это дело бэкапить.

(14) А еще MS SQL начиная с определенной версии умеет FileStream.

(14) А еще MS SQL начиная с определенной версии умеет File Stream.

> А файловая система это как раз самая удобная и продуманная база данных для хранения файлов.
Смотря какие файлы, размеры и количества.
По крайней мере на винде разница в скорости обращения к каталогу с <1000 файлов и >100000 файлов просто драматическая. А для SQL что тысяча, что миллион - нормально тянет.

(17) А в чем драматизм папки с 100000файлов?
Не замечал.
Раньше да, было такое - такую папку проводник мог час открывать, особенно когда оперативки мало.
Сейчас проводник открывает папку моментально.
Если прямой доступ к файлу из скрипта - разницы нет что 1 файл в папке, что 100000.
Ну по крайней мере в ntfs так.

Если брать по масштабам, то для каждого ключа "Контрагент-Проект" может быть до 10Гб файлов.
Если же все же использовать SQL базы для хранения этих файлов, то как лучше быть на платформе 8.3 если для каждого ключа "Контрагент-Проект" создавать свою базу?
Пользоваться внешними источниками данных или без них? Будет ли преимущество?

(19) Что за файлы? Тип, размер? Общий объем который планируется?

(18) Проводник?!? :) Вы, наверное, из тех айтишников, которые замеряют скорость дисковой подсистемы на сервере пару раз скопировав файл в ФАРе?

Проводник не показатель, нужно измерять реальные процессы. У меня когда-то на сервере с рэйдом и приличными дисками с нагрузкой порядка 150 пользователей чтение папки ~60000 файлов  с помощью rsync для синхронизации занимало несколько минут.

(12) с какой радости я тебе должен какие-то примеры приводить? Я ответил на вопрос автора, как сабж лучше сделать. Зачем он автору, я понятия не имею. Но имею в опыте ситуацию, когда такой велосипед был необходим. И нет, ни какой скорости он, естественно, не добавляет и пользовательский экспириенс не улучшает. Это делается для технических или безопасных целей чаще всего.

(21) Поясню для непонятливых - вы говорите что скорость обращения к файлам в папке с множеством файлов низкая.
Так вот - нихрена подобного.
Она высокая.
Низкая она была раньше - в проводнике, ибо проводник прожевать не мог такой вывод.
А прямой доступ - высокий всегда.
Сейчас даже проводник моментально прожеввывает такие папки.

Вот сейчас проверял - создал папку с миллионом файлов размером 4к  и попробовал скопировать из нее сотню файлов
Потом попробовал скопировать сотню файлов из папки где всего сто файлов - скорость копирования такая же (в пределах погрешности)

(0)
Хранение документов на диске - используется многими и давно и успешно.
Единственный момент, чтобы в случае работы с копией базы, том, где хранятся документы, не уничтожили и не испортили документы. То есть нужен какой-то предохранитель
Я недавно допиливал одну базу, пользовался как основой вот этой статьей.
http://catalog.mista.ru/public/529067/

Там правда для обычных форм.

(25) Ну обычно на сервере где продакшен крутится с тестовыми не работают.

Если работают - монтировать папку симлинком с  ID базы например.

(11)
УХ - 1с:Управление холдингом

в нем предусмотрена интеграция с 1с:Документооборот в плане хранения файлов

"Что за файлы? Тип, размер? Общий объем который планируется?": word, excel, отсканированные документы.
Проектов в год порядка 200 штук. На каждый проект порядка 10 Гб файлов - файлов очень много может быть.

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

(23)
>> Поясню для непонятливых - вы говорите что скорость обращения к файлам в папке с множеством файлов низкая.

Я говорю "разница в скорости обращения к каталогу...". Где вы видите слово "файлы"?
И описываю рабочий кейс: синхронизация каталогов с помощью rsync. Такой сценарий работы подразумевает большое количество чтений содержимого каталога и малое - файлов.

>> Низкая она была раньше - в проводнике

А раньше, это когда? А где ТС описал свою инфраструктуру? Может быть у него легаси на NT4.

>> А прямой доступ - высокий всегда.

У вас есть информация о том, как у ТС организован доступ к файлам? Может быть по сети, тогда ваш "прямой доступ" мимо кассы.

(21)Не обязательно все хранить в одном. Раскидывай по подпапкам разделяя их по количеству, дате или любому другому признаку, который позволит +- равномерно размазать файлы по подпапкам. И нет проблемы.

(29) А зачем к каталогу обращаться?

Обычное хранение - к документу в базе 1с привязываются например сканы первички в pdf.
Потом их нужно будет выдергивать оттуда.

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

Предполагается что инфраструктура современная от winserv2008 и выше, музейные экспонаты двадцатилетней давности не рассматриваю.

По сети или не по сети - пофиг.

(30) Ну по дате не лучший способ.

Самое удобное - при сохранении файла считается его хэш.
Имя файла - хэш файла.

Т.е в базе хранится путь к каталогу где хранятся файлы, и хэши файлов.

Если надо по папкам то делается один-два уровня иерархии по первым символам хэша.

(31) если запись в ОДНОМ каталоге - то лям файлов завалят любой сервак...

уже поле 20 тысяч файлов заметны проблемы, 100 тыс файлов валят вполне приличный сервер...

по этому по любому нужно делать каталоги...

я в свое время писал ТЗ на подобную систему, в кратце

1. каталоги по годам
2. внутри каталогов по годам каталоги по функциональным направлениям (например юридические, и бух хранятся отдельно)
3. при большом количестве файлов нужно дробить еще глубже...

ну и еще замечание - ОБЯЗАТЕЛЬНО нужно ограничивать размер файлов...

стандартный скан А4 влезает в 300кб, по этому я ставлю ограничение 500кб на картинки и файлы, а на зипы 5 мегов...

(33)Завалит в каком смысле?
Случайное чтение будет медленно идти, при множественных запросах к файлам?
Так обычно прикрепленные файлы это статика - они больше хранятся чем используются.

По поводу максимального количества файлов в каталоге и его влияния на производительность.
Проще применить решение, автоматически распределяющее файлы по разным каталогам, чем сидеть и ждать подтверждения, что в 21м веке может случиться то же самое, что случалось в 20м. Это как руки мыть после туалета. Если этого не делать, то в большинстве случаев ни чего тебе не будет. Но, когда будет, ты сразу поймешь, что риск был бессмысленный, однако будет уже поздно.

Это все равно, что говорить: "Best practices - гогно потому, что я не встречал случаев, когда не следование им приводило к негативным последствиям". Когда встретишь, поздно будет что-то менять

(36) Дык потестить можно какая там предполагаемая нагрузка будет.
$array = New-Object -TypeName Byte[] -ArgumentList 4kb
$obj = New-Object -TypeName System.Random
$obj.NextBytes($array)
for ($i=1; $i -le 1000000; $i++) {
Set-Content -Path F:\test\File$i.txt -Value $array -Encoding Byte
}

Ну и потом выборку нужную сделать и замерить время.

(38) к (37) надо что-то еще добавлять разве?
все эти твои тесты не будут стоить ни черта, когда продуктивная инфраструктура изменится относительно тестовой. Переедет в дудущем вся эта халабуда на другую какую-то СДХ или/и ОС и выяснится, что количество таки имеет значение. Что ты будешь с тестами своими делать? Вопрос риторический.

СХД, а не СДХ

что, про стандартный функционал БСП действительно никто не знает?

(39) Ну разбивку по папкам как я уже говорил сделать не трудно.
Делается по первым буквам хэша.
И распределяется равномерно и поиск шустрее, и по дискам раскидать можно, ежели объем большой.

"что, про стандартный функционал БСП действительно никто не знает?" - а что в ней относительно данной задачи есть? Подскажите пожалуйста.

И Так все таки лучше хранить связь с объектом 1С в регистре сведений или справочнике с учетом огромного количества файлов?
И при рассмотрении хранения файлов в другой базе (хотя для проекта будет предусмотрен вариант хранения) пользоваться ли объектом внешние источники данных?

(43) тут вроде очевидно: если тебе надо на файл ссылаться, то справочник. Если достаточно к чему-либо прикрепить - РС. В типовых как правило делают справочник или справочники.

Мне фактически надо что:
1) Возможность сохранения файла, прикрепленного к объекту.
2) Открытие/редактирование файла, прикрепленного к объекту.

И тут выбор почему между справочником и регистром сведений: при большом массиве данные какое обращение будет быстрее и объем хранения данных?

В типовых и в частности БСП используют "Присоединенные файлы".

Читал про "Веб-сервис работы с файлами" в Документообороте. но если у каждого проекта будет своя база, то поднимать для каждой базы веб-сервис это затратно...

(45) В БСП всё, что тебе надо, уже реализовано.

"В БСП всё, что тебе надо, уже реализовано." - и даже хранение файлов в другой базе данных?

(48) посмотрели бы документооборот просто, если права сильно не развешивать и хранить в томах, вероятно не станет тяжелой и получите в довесок извлечение текстов и полнотектовый поиск. мб еще какие плюшки понравятся

(43) все - хранение на диске, в облаке, индексирование и поиск по текстовому содержимому файлов, прикрепление к объектам, версионирование файлов, раскладывание файлов по папкам....

(48) зачем "в базе"?

То есть все-таки большинство к хранению файлов на диске с использованием томов хранения файлов (как в БСП)?