Часто возникает такая задача: нужно хранить данные (файлы) привязанные к определенным объектам 1С:Предприятие. Например это обычная задача у алкогольных компаний. Нужно хранить сертификаты, удостоверения качества и т.д. Часто бывает, что нужно хранить фотографии товаров, копии договоров и т.д. Объем этих данных может быть достаточно большим. Возникает вопрос где их хранить. С одной стороны можно хранить внутри БД. Это позволяет делать восьмерка.
Мы сейчас в офисе обсуждаем этот вопрос. Прошу присоединяться.

Голосовалку не буду прикручивать т.к. нужна именно аргументированная дискуссия.

подумайте про стратегию резервного копирования - восстановления.

(0) Сначала будете хранить БД, потом как справочник с ХранилищемЗначения выйдет в топ таблиц по размеру - начнете резать. Имхо - хранить в другой сиквельной базе с запросами из БД.

(2) Это одна из проблем, но она легко решается.
Вопрос больше сводиться к тому, зачем нужна большая база где храниться все.

имхо, проще/надежнее/удобнее - просто хранить на файловом хранилище.

(0) мое имхо: лучше вне базы...

(4) без объемов данных и специфики задач топик = пятничный трёп

(5) Но возникает проблема обеспечения ссылочной целосности. Кто-то может просто удалить файл или переименовать его. Это тоже решаемо, но определенные трудности в этом есть.

(6) Ну давайте возьмем для примера алкогольное предприятие.

(8) Каким образом?
хранилище файлов должно быть недосягаемо для всех.

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

Поддержу (6), хотя (7) дело говорит. Кто-то фильмы хранит и не жужжит.

(8) права доступа чтение/изменение, добавлять - только через программу.

сканы могут быть и метровые, файловый вариант надежнее

Храню на FTP. Файлов сотни тысяч, объем примерно 15 гиг

+9 За 2 года работы папка с картинками распухла до 40ГБ.

(16) ответ очевиден
хранить 40 Гб внутри 1С нельзя

+16 Например сейчас столкнулись с такой проблемой. Периодически по сети не удается достучаться до нужной картинки и она не печатается. Удалили часть картинок - проблема пропала.

(15) по-моему, один из самых оптимальных вариантов

А, чем плохо хранение файлов в СУБД?

+20 Тем более восьмерка это легко позволяет сделать.

(17) Почему? Естественно в скульной базе, а не в файловой.

Наврал. Файлов 282 932, размер 71,7 Гб  :)

(20) SQL Server'у, по идее, по фигу - будет хранить. Но вы увеличите на 40 Гб размер бэкапа, а значит и время восстановления, в случае сбоя, существенно увеличится.

(20) подумай хотя бы о том, сколько времени займет создание ежедневного бэкапа, или восстановление.. реиндекс.. нахера этот гемор?

(21) тяжко поддерживать + хранилище в 1С - вещь в себе...

+(25) потом эти бэкапы нужно где-то хранить.. у тебя достаточно ресурсов для такой задачи?

(24) Проблемы индейцев шерифа не волнуют. Есть повод пойти к генералу и выбить новый сервак под это дело. Заодно и свой домашний комп обновить :-)

(28) звоню твоему шефу...

Хранить в БД.
80 гектаров на прошлой работе было, большинство - сканы сертификатов по алкоголю.
Полет нормальнный.

Мы отдельную таблицу в SQL сделали (база SQLная), туда все запросами посылаем. А так было ХранилищеДанных (но уж очень большое стало).

а смысл гонять туда-сюда через 1с/sql большие файлы?

насколько помнится - работали под ораклом, там все хранилось в базе - и как то и бекапы создавались...

(29) А куда он денется? У алкоголиков учет строгий. Можно налететь на куда большие санкции, чем стоимость нового сервака.

Аналогичную задачу сейчас решаю.
В базе на данный момент более 4 Гб файлов.
Решил выгрузить их в каталог, и очистить хранилище, а в базе ссылки хранить.
Обработка вроде не сложная но пока не продумал как хранить. Наверное по УИДу...

Вопрос по теме: можно-ли узнать объем конкретно файла в хранилище?

(35) В http://www.kb.mista.ru/ статья есть

Но идея хранить на фтп мне тоже нравится.

(35) У меня файлы имеют вид "00181625-4a2d-11dc-ab96-0004234739b4_#20080314181226.jpg"

(36)Сейчас поищем. спасибо.

(38) А новые файлы как на ФТП загружаешь? Через 1С? Какого рода файлы и к каким документам, справочникам привязаны?

(20) [А, чем плохо хранение файлов в СУБД?]
деньгами
для sql  нужен быстрый рэйд и полный  бэкап
для картинок не нужен рэйд и достаточен инкрементный бэкап

(33) Дело не в том, что бэкапы не будут создаваться, а в том, что размер и время создания\восстановления существенно вырастут

(38)Это существующие файлы могу сохранить так (но у меня необходимо чтоб открыть можно было только из 1С)
А с новыми, который пользователь добавляет в базу?

(40) Через 1С. Каждый нужный объект метаданных имеет свою папку. В ХранилищеДополнительнойИнформации добавил ВнешнееИмяФайла-строка и ВнешнееХранение-булево

(43) Пару-пятерку процедур изменить

(44) Загружаешь в 1С и тут же выгружаешь на фтп, а из 1С удаляешь?

И я свои 5 копеек, т.к. пробовал много вариантов:
Если дв.данных много, тогда крайне не рекомендуется хранить совместно с 1Ц в одной базе. Причина - архивация. Проблема не в размерах, а в стратегии архивации. 1С надо делать 2-3 раза в день архив по изменениям с циклом, например месячным. Картинки надо архивировать только измененные и достаточно раз в пол.года (бумажные же копии то все равно есть).
Если все делать раздельно, то можно разнести по разным серверам, по времени развести регламентные обработки и т.д. и т.п. Есть одна крайне неприятная черта - в распределёнке придется городить огород с репликациями SQL, но это уже другой вопрос
В файловом варианте хранить нельзя! Из-за низкой надежности, низкой скорости доступа и низкой скорости поиска. Если бы это утверждение было бы не верным, то 1С-ку ни кто не переводил бы на SQL при больших объемах.
В общем мое мнение хранить в отдельной MS SQL или PostgreSQL базе (у нас в МС-е сейчас хранится)

(46) Нет. Выбранный пользователем файл сразу отправляется на ftp

а такие "00181625-4a2d-11dc-ab96-0004234739b4_#20080314181226.jpg" имена файлов как получаются? Юзеры файлы обычно так не называют файлы.

// функция получает имя файла для хранения
Функция ПолучитьВнешнееИмяФайла(Ссылка, ПолноеИмяФайла) Экспорт
   
   ИмяФайла = ПолучитьТолькоИмяФайла(ПолноеИмяФайла);
   ВнешнееИмяФайла = Строка(Ссылка.УникальныйИдентификатор())+"_#"+Формат(ТекущаяДата(),"ДФ=ггггММддЧЧммсс")+"."+ПолучитьРасширениеФайла(ИмяФайла);
   
   Возврат ВнешнееИмяФайла;
   
КонецФункции

(49) ну че тупишь-то?
(Строка(Новый УникальныйИдентификатор) + "_#"+Формат(...))..

(50) ;)

(51) Ты знал :D

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

Файловый вариант(или ftp) позволяет так же работать с теми же файлами сторонним приложениям. Я считаю что чем больше универсальность решения при одинаковой скорости работы тем лучше.

(54) большими объемами труднее рулить. Скорость ниже. Надёжность ниже. Соответственно денег на поддержание больше. Проходили не раз.
Мои все хранилища поддерживают хранение минимум внутреннее, файловое и ФТП. Последнее самое медленное, время тратится на установку соединения!

А мы не спешим. 150 миллисекунд или 40 миллисекунд, без разницы :)

(56) Не знаю, некоторые сервера дольше отвечают. Мы пробовали по всякому и на SQL-е только плюсы. Если минусов нет, тогда зачем городить огород? Может я не знаю чего-то?

Хранить в БД. Храним конструкторскую документацию, сканы. Немеряно.

(47) Полностью согласен.

(58) А обновляться? А архив сколько по времени делается?

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

(60) Так какие плюсы перед отдельной БД? Хорошо, можно и с другой стороны: В типовых конфах (особенно на 77) часто фаловый вариант и точка, доработчики и прочие последователи по накатанной используют сторонний опыт. Я прав? Или другая причина? Вообще, по трудозатратам и так и так одинаково получается. Хотя в файловом варианте немного больше, ведь надо предусмотреть то, что в БД уже есть (сохранность, контроль, распределёнка, расположение с точки зрения хранения и т.д.). Теперь давно мучавший меня вопрос, если файловый вариант сложнее и не выгоднее, тогда какой плюс?
...
Зацепился я сейчас за тему только по тому, что надо внедрять клиенту хранение дв.данных. Сделал что-бы можно было хранить где угодно, настройки делаю под СКЛ, за что беру деньги. Так вот если я не прав, то может лучше остановиться сразу?

(61) Файловый вариант в каком смысле?
У меня так - база на сервере. Файлы будут отдельно хранятся в сети, ввиду не высоких требований и редкому к ним обращению, и желанию повысить скорость работы с БД (архивация, обновление...)
Сейчас архив базы = 4,3 Гб. Архив базы без файлов = 50 Мб.
Считаю что в моем случае целесообразно хранить отдельно

Имхо, есть неразбериха в понятии "хранить в базе" - хранить в значениях типа хранилище значений или в SQL базе, но не в таблицах 1с (отдельная SQL-таблица).

(62) Да, наверное я не так выразился. Дв.данные предлагаю хранить именно в отдельной от 1С БД. Ни в коем случае не совместно! Если совместно, то в хранилище значений и на малых объёмах.
При чем мне понравилось, когда 1С в любом виде (файловая MC SQL или PostgreSQL) и дв. данные тоже в любом виде, в зависимости от настроек, условий и команд

Вопрос, тем кто использует отдельную СУБД или ftp для хранения картинок. Как у вас организован процесс извлечения файла для печати? По моему его нужно будет где-то на время сохранить, для печати?

Поднимем ветку

Тезисно:
1. Если БД 1С фаловая или postgres (да и бесплатная DB2), то файлы однозначно отдельно.
2. Если файлы 2-3 МБ и более занимают не более 20-30% объёма, то стоит использовать регистры сведений (или справочники) с реквизитом - хранилищем значения.
3. Если объектов более 200000, то их имеет смысл хранить в БД - файлопомойки тут начинают грустить.

Плюсы хранения в БД:
1. Транзакционность работы и целостность данных обеспечить на порядок проще.
2. Бэкапы (целостные) делать на порядок проще. Т.е. (55) неправ - надёжность выше.
3. Логи изменений автоматом формирует журнал регистрации (кто и когда правил объект).
4. Не нужно изобретать общедоступное хранилище по сети или специальный набор серверных функций для получения данных. Нет проблем с репликацией.
5. Обработка данных на сервере предприятия очень быстра (т.к. канал до СУБД обычно очень хороший).
6. Можно нарулить права на уровне конфигурации 1С (а не файлового доступа)

Минусы:
1. Для файлов начиная с 3 МБ затраты сервера предприятия и СУБД на передачу данных и достаточно велики.
2. От 10-20 МБ возникает еще и вопрос прожорливости по памяти.
3. Невозможность потоковой работы с данными одного объекта (приходится целиком считать, потом записать, потом последовательно читать с локального диска - бр-р-р)
4. Для файлов сканированных документов (часто фармацевтика, алкоголь) проще организовать быструю и эффективную печать с сервера предприятия больших порций макулатуры, чем с СУБД передавать на сервер предприятия, потом на клиента, потом на диск (временный файл), потом с диска в память, потом на сетевой принтер.
5. Лог транзакций при больших объёмах записи файлов записывается гораздо интенсивнее.

Если задача хранить кучу картинок 50-1000 КБ и показывать их юзерам, то однозначно в СУБД 1С. Если на каждую реализацию надо распечатать 20-50 сканов сертификатов, каждый по 10 МБ, то пожалуй придётся работать с файлами или создавать отдельную СУБД не 1С (в MS SQL 2008 есть специальный механизм - FILESTREAM: http://msdn.microsoft.com/ru-ru/library/bb933993(SQL.105).aspx ). Каждой задаче - своё решение.

(55) - сорри неправильно понял. Надёжность хранения в ИБ - ВЫШЕ :)

Я бы завел вторую базы непосредственно для хранения данных больших объемов, с обращением по оле по внутреннему идентификатору. Как вариант просто

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

(11). И че? Гигабайты - это какая-то существенная проблема для современной СУБД?
(0). Почему бы и не хранить в БД, в случае с v8 в хранилище? Сильно больше места чем при файловом варианте не будет занимать. Ссылочная целостность и удобный быстрый поиск нужных данных обеспечивается. Картинки на самом деле занимают не так уж много места, особенно если не фотографировать товар с полным разрешением камеры (такое качество нафиг не нужно).

(41). Точно для картинок не нужен бэкап, а если пропадут на файловом хранилище, как восстанавливать будут? Заново сканить и фотографировать?

В 7.7 я хранил счета, договоры в файлах, в 8-ке - внутри базы 1С.
Доработка типовой была минимальной - поставил ограничитель (константу) на максимальный размер загружаемого файла (чтобы мультики в БД не заливали).
В принципе, удобно.
Более того, я знаю конфы, где в БД сохраняются pdf всех ранее распечатанных клиентам документов (чтобы изменения в НСИ не влияли на документы). Тоже работает при разумном анализе места.
Но наиболее разумный способ, безусловно - хранение картинок во внешней БД.

(70) ну а промежуточные файлы создаете перед печатью?

я сейчас реализую следующую технологию

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

(74) Зачем? Картинки хранятся же в базе.
Вторая база это архив - в ней только старые изображения

(75) Я имею в виду когда данные хранятся в СУБД. Файл нужно извлечь из СУБД сохранить в файл, а потом напечатать.

(77) Нафига? Достаем из хранилища картинку и пихаем ее в макет

(78) Я про 7.7 сейчас говорю. Пардон, забыл указать.

аа.. 7.7 намного проще в файлах хранить.. не в субд

(80) Что проще это понятно. Я сейчас модернизирую существующию систему. Хочу перевести ее на работу с СУБД.

(41) Чем плох инкрементный бэкап для базы?

(0) лучше файловый на ssd, печать, если возможно, сразу без предварительного просмотра

(83) это если все в терминале сидят