v7: Хранение картинок, непосредственно в БД 1с 77 #810909

Добрый день. Необходимо реализовать хранение изображений в БД на платформе 1С 77. Погуглив понял что вариантов решения много, решил спросить старожилов и гуру, совета, каким инструментом лучше воспользоваться, чтобы более быстро и корректно это всё работало?

Вотипрям стопудово именно в базе? Снаружи не устроит?

binfile.dll и учти, что в 7.7 ограничение на размер строк, более 4 метров не влезет

Не-а, надо именно в базе. Снаружи механизм есть, отработан, всё ок. Надо именно в базе, штатными средствами я так понял никак, поэтому вот и спрашиваю :)

Спасибо, сейчас погуглим

Умные люди и в восьмёрке серверной часто снаружи держат, а ты семёрку хочешь ненужным нагрузить. На 90% задача неправильная.

ну может они проблему синхронизации картинок при использовании урбд хотят решить

Если нештатными, то можно использовать объект BinaryData (1С++). Например, как тут:

Даже если и РИБ - он не один в распределёнке работает. В новом тыщелетии пора уже синхронизацию каталогов освоить.

Большое спасибо, приму ваш комментарий во внимание. Очень рад, что вы проявили интерес к моей теме. А вообще вот вам вопрос: В 1С БП 3.0, к документам в базе можно прикреплять различные файлы и хранятся они в БД, а не в каталоге БД. Решение хранить файлы в базе принимали разработчики конфигурации. Верно ли было их решение, и как вы считаете, почему они решили эту задачу хранения документов в базе именно таким способом?

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

Да, нашёл такую настройку :) Виноват, принимаю :) Постараюсь донести до заказчиков, что лучше бы таки хранить не в базе, спасибо :)

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

Даже более не только на внешних томах но даже можно хранить прикрепленные файлы на яндекс диске

мое ЛИЧНОЕ мнение по поводу хранения картинок в базе если рост базы из-за картинок прогнозируем и устраивает на 5 лет вперед - то предпочтительно хранить в базе (например стоит ограничение 300кб на 1 файл, и файлов в день добавляется около сотни) а вот если рост базы НЕ ПРОГНОЗИРУЕТСЯ - тогда только во внешнем хранилище

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

А при выгрузке/загрузке всё сохранится? :)

нет

и оставить их доступными для шифровальщиков :)

Так файлы БД тоже никак не защищены от этого :)

Архивы картинок однако тоже нужно делать

я буду шифровать по 10 файлов в день, через сколько времени ты поймешь, что в твоем бекапе больше половины картинок восстановить нельзя?

для SQL варианта - защищены

Ты только 1 бэкап делаешь?

В плане SQL, да, норм тема ваще. Работа через посредника с базой считай, ты его только спрашиваешь, а он уже сам читает базу и отвечает тебе.

я про то и говорю, если портить по чуть чуть - ты заметишь только через несколько месяцев... по этому хранение всего вместе в едином виде куда более безопасно чем кусками

Смотря, что за файлы, смотря какое количество... Чем больше файлов и чем они меньше, тем выгоднее их хранить в базе. Я перевёл внешние файлы в базу, когда количество файлов размером порядка 5-10 килобайт стало измеряться сотнями тысяч. Сканы размером сотни килобайт остались внешними.

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

Делал и как 2 и как 7 2 это скорее всего мой объект ну или у меня такой же. Преимущество 2 храниться в документе или в справочнике и передается по УРБД Преимущество 7  более грамотное решение. Если картинок много и большой размер то делай как 7 и заведи отдельную sql бд и храни все там ( со ссылкой на iddoc ( это индекс )

Когда будет картинок более 50 000 тормозить будет по черному. Минус этого решения что  на хвосты файлов много места теряется и нет никакой логической целостности такого подхода. но если файлов будет до 50 000 и надо очень  быстро развернуть то только в этом случае так надо делать

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

сохраниться

Я бы не стал привязываться к коду. Код может измениться. Есть внутренний идентификатор объекта. Он неизменен. Вот к нему можно привязаться. Т.е. полный путь для файла будет: Константа.КаталогХраненияФайлов ИдентификаторОбъектаВБазе имяФайла.

если базы "разные" например обмен по modу, то и id разные. короче нет универсального совета, нужно по месту смотреть

У нас сертификаты ( их изображения ) привызаны к прихбн. для этого и был сделан bfile где то в 2001-2002 году. И как ты будешь решать такую задачу при условии что база УРБД распределеная.

Картинки можно хранить на яндекс диске или т.п. сервисе. Бесплатные объемы около 30Гб (более чем достаточно). На точках так же ставится клиент, всё само синхронизируется. У меня так настроено у пары клиентов.

не всякий окажется ставить сомнительный авнософт на сервере. Сами юзаем дроббокс. Для домашнего использования - классная вещь, но на сервере который работает 24/7 постоянные косяки с обновлением

в 20001 году этого не было. Что будешь делать если интернет в филиале пропадет дня на три-четыре ?

Ставить или не ставить это конечно субъективно. У меня работает пару лет. Есть нюансы, но они решаемы. Если интернета нет, то и обмен не будет работать. Какие тут обходные пути? Отправлять курьера с флэшкой?

Если кому-то мешает много файлов в директории,то можно или по папкам раскладывать или обьединять несколько файлов в один,но если у вас нтфс,то там каталог в виде индексированного дерева и на скорость работы количество файлов сильно влиять не должно

У нас инфа по номенклатуре, в т.ч. картинки, хранятся на одном из хардов серверной. Ёмкость 73Гб. Доступ к БД - Терминальный, 4 филиала в разных городах. Так что все видят одно и то-же. В Справочнике "Товары" показывается фото. Хранение (и показ) организованы через константу - "Постоянная часть пути к файлам", папка типа I:/RTFM В папке содержатся подпапки с именами = коду Товара (ну, Номенклатуры, если так понятнее ТиС-овцам). В подпапках с кодами товаров содержится любая инфа, в основном это файлы с сертификатами *.pdf и фото, если оно нужно. Т.о. в инете ничего не хранится, ибо что в инет попало - стало чужим.. Это на считая отрубов от инета. В Справочнике есть реквизит "НазваниеПапки", в нём - полный путь к картинке. Если реквизит не пустой - в карточке товара показывается картинка/фото. Заполнение реквизита - по нажатию кнопки "Выбрать". Ниже - кн удалить фото. Это я к тому, что вариантов много, все индивидуальны, в функции предпочтений предприятия. Облако? - За ради Бога!..

В Проводнике:

В УРБД работает передали сертификат один раз и все работает. Т.е. клиент пришел и просит сертификат за  01.07.2017 нет интернета ничего дать не сможешь в моем случае для выдачи переданного в филиал сертификата интернет не нужен

Можешь поверить влияет и сильно. не зависит  фат или нтфс но хотите идти таким путем то идите. опять же при большом количестве файл сбой по диску и получишь непредсказуемое состояние в этих файлах. sql гарантирует целостность данных. насколько важна целостность зависит от задачи.

Количество папок у нас - огромно, и при непосредственном просмотре тормозиииит.. Это - да, не отнять. Но непосредственно  на этом диске делать нечего, всё организовано обработками. Но на работу БД не влияет, 9 лет с лишним менеджеров радуют фотки в карточках товара :)

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

Ну может такой вариант и имеет право на жизнь при небольшом количестве филиалов и документов. При больших объемах не уследишь за рассинхранизацией таких далнных.Здесь также разные механизмы разрешения колизий а значит данные могут разъехаться. У меня сертификаты хранятся в самом документе что гарантирует соответсвие документа и самого сертификата(картинки сертификата)