Где лучше хранить фотографии товаров - в ДБ или вне ее #756122

В базе данных около 15 тыс товаров хотим добавить каждому товару фотографии  не скажется ли это отрицательно на базе данных. Может кто-то имел опыт хранения большого количества изображений в УТ 10.3.Просто в других БД реализовано хранение  во внешнем каталоге

это приведет к тому, что вам где-то придется хранить 15К изображений. В базе или нет - не такая уж и большая разница. По сути, если они будут в БД, то их будет содержать каждый бэкап базы, а, если - в отдельном каталоге, то можно бэкапить то  и это по разным расписаниям. Кроме того, базы обычно лежат на быстрых и дорогих дисковых массивов, а скорость доступа к изображениям не так уж и критична, так что в ряде случаев картинки выносят из базы, чтобы снизить стоимость их хранения.

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

хорошего мало будет. База вырастет немеряно

почему немеряно? На 15К картинок и вырастет.

Смотря какие фотографии...если большие, тогда лучше снаружи +1

Смотря какие картинки. Когда впихивали изображения, я обратил внимание на лавинообразный рост базы. Глянул чисто из интереса, а там 4-8 мегабайтовые фото или скрины.

у меня стоит ограничение на размер прилепляемых файлов 500 кб, этого хватает на скан А4 300дпи в джимпеге, 15к картинок займет 7.5 гига, в общем конечно это совсем не критично, но все-же...

Лучше хранить отдельно, а в базе ссылки только.

я-бы сказал так: если размер картинок больше чем размер базы без картинок - лучше хранить отдельно, если меньше - лучше внутри... то есть размер картинок внутри базы не более 50% от общего размера

а на счет реализации хранения во вне как это реализовать?

Каталог с файлами, доступный серверу 1с. Или пользователям, если файл-серверный вариант.

У меня 25 тысяч ПДФ файлов. Лежат отдельно. Рекомендую.

я за хранение отдельно на диске

Посмотри в типовых, там это уже реализовано.

Файлы лежат на отдельном диске. Сама база 4 Гига в ДТ.

В одном каталоге все? Не тормозит?

И про бэкап изображений обычно забывают, а потом случается "упс..." Кстати, еще вариант - хранить в отдельной базе.

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

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

Может когда-нибудь 1С научится использовать FILESTREAM в MSSQL...

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

А чему там тормозить? Обращение идет по имени файла.

разве голый скуль это умеет? (без надстроек?) или не только скуль но и остальные СУБД с которыми работает 1с

мда... помести в каталок 100 000 файлов и просто попробуй его открыть проводником....

А зачем его открывать проводником?

MSSQL умеет "из коробки" начиная с определенной версии. Про остальные субд я ничего не говорил.

Уже давно как. Еще в дремучем (по сегодняшним меркам) VFP 9.0 был тип BLOB.

"в запросах, когда через точку что-нибудь читают, не тормозило чтением картинки" // в запросах оно как раз и не тормозит

Так 1с работает не только с мс. поэтому пока оракль и прочие под(д)елки не сделают совместимый интерфейс - не будет такого.

по дефолту - нет... кроме того тут много моментов связанных с безопасностью...

Также можно включить и при установке.

кстати классический вопрос (его спрашивают при тестировании 1с): если Вы хотите хранить файлы отдельно на сервере 1с, какой путь нужно указывать? подвох тут в том, что КЛАСТЕР 1с не гарантирует выполнение кода на конкретном сервере, по этому хранить можно ТОЛЬКО на сетевых ресурсах доступных для всех серверов кластера, либо во встроенном репозитарии, но это то же проблема...

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

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

а тебя не напрягает, что все картинки можно грохнуть нажав вместо копирования перемещение,

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

чтобы при чтении объекта каждый раз не тянуть сканы, нужно, чтобы сканы не в объекте хранились, а отдельно. Например - в регистре сведений. Или в объекте ТЧ со ссылками на справочник, в котором уже картинки.

по файлам хранить если будеш, проблемы с риб сможешь поиметь.

Реад-онли для всех кроме сервера 1С

ну я это и имел ввиду

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

Вас это беспокоит? Вы хотите поговорить об этом?

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

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

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

Храним в отдельно скулевской базе, быстрее поиск, проще бакап.

EXEC sp_spaceused $Справочник.Файлы - 41936 строк. 7 гб на диске. ИМХО - не стоит заливать в БД. скуль кеширует некоторые данные в оперативку при доступе, а эта информация там нафиг не нужна.

> Единственное на что следует обратить внимание - увеличится время обслуживания базы данных. +1 нет смысла оверхедить работу.

у меня картинки типовой размер 310на340 (вполне хватает чтобы увидеть что за товар) - размеры картинок большинство подавляющее - ~15 Кб. Для 15К картинок объем будет меньше 300 Мб. если картинки нужны чтобы подробно рассмотреть - тогда считатйе сами...

у меня по рибу фотки передаются - когда меняют :) (поэтому сделал в базе)