Делаю базу для хранения картинок в ней как во внешнем хранилище. Есть подозрение, что будет удобнее, если мы ограничим пользователей требованием к добавляемым рисункам (сертификатам) номенклатуры. Ограничиться размером 800х600 и выбрать самый лёгкий формат. вот какой только хотел у вас спросить. Сам пока думаю, что jpeg.
И мне еще обработки для группокой печати нужно написать будет.

Зачем база? Храни в томах на диске. Это реализовано в БСП ну или в Документообороте

(1)как зачем база ... целостность

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

раз все молчат, значит JPEG

(3) хранение в томах  на диске это рекомендуемых способ разработчиками БСП.

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

(4) сам формат не важен. но кошернее и солиднее в пдф...

(0) лучше в томах хранить. Хранение картинок в блобе - это в будущем невозможность реструктуризации, ТИИ и всего остального

(7) ну и выгрузки в dt по 10 гигов :)

А я против. Блобы в базе для того и были созданы, чтобы хранить бинарные данные неотъемлемо от базы. Хранение в отдельном каталоге - колхоз какой-то.. да, это решает некоторые проблемы, но несерьезно.

(7) а если в томах, то потом можно невозбранно всякие пакетные конвертации и прочие круть-верть (дедубликации к примеру) какими-нибудь imagemagick'ами делать. Если оно в БД, то это тоже можно, но дольше и не в пример геморройнее

(9) некоторые это какие ?

(11) Ну вышеозвученные сложности с ТиИ, размером выгрузки..

(9) ты просто не видел, что бывает, когда несколько терабайт в этих блобах. Мегатонны говен, с которыми не то, что не сделать ни чего, их даже по головам не пересчитать

(9) у меня есть у клиентов база УТ11
там пришпилина в файлы документация по продаваемым станкам и опциям - порядка 70 гигов..

+

в базе сидит 20 почтовых ящиков каждый в среднем гигов 20 ибо со вложениями..



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

(13) А нефиг порнуху в базе хранить. А вот например скану договора с контрагентом или фото изделия для каталога там самое место.

(12) так они то как раз и решаются выносом файлов в тома..
нет разве ?

(15) ну да.. у нас техдокументации 70 гигов..

(14) "всякие там обновления, пересчеты итогов и прочие выгрузки ?"
Блобы у 1с хранятся в отдельной таблице и всяким там обновлениям и пересчетам итогов на них обычно пофиг.

(18) а 1Су ?

(15) Ну вот у меня таблица, в которой 4 с схером ТБ сканов именно договров, допсов и приложений к ним. Истинно тебе говорю - хранить это в блобе было хреновой идеей

(15)а в каком формате храните и в основной базе или во внешней?
(14)а если только картинки выносить во внешнюю базу, то какой смысл её обновлять или там итоги пересчитывать? Я же возьму 1С документооборот и буду его как внешний источник использовать. К нему будет просто обращение идти не постоянно.

(19) Аналогично. Хранением данных занимается sql, а для него хранить блобы это детская игра. Если 1с таблицу блобов не трогает - то абсолютно пофиг, сколько она занимает на диске..

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

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

(21) >Я же возьму 1С документооборот и буду его как внешний источник использовать

угу, удачи

(22) причем прелесть работы с файлами в том что ты можешь вынести тома на СЕТЕВЫЕ ресурсы и организовать иерархию этих томов..


то есть поставил нас, вшпилил туда 10 тб на САТА и вынес все файлы туда..
а твой скуль, вполне себе крутит базку на 1 гиг на SSDшках.. и все летает. и все счастливы..

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

(21) ты для начала тестовую подключи документооборот к любой базе и поюзай эт работу через вебсервисы..  :)

(26) никогда не угадаешь что именно надо будет хранить пользователям..

сейчас это скан договора, а завтра ПДФ с описанием станка на 100 страниц с картинками весом в 70 мегов..

(21) пока jpg вроде самый оптимальный, еще пожать его можно, убрав лишний мусор из файла. может есть еще лучший формат

векторная графика, вроде еще меньше

(29) с базой работать пользователям
они это делать не будут

как отсканировалось - так и ляжет в базу

отсканировалось в 300 дэпэай в цвете - будет у вас цветной счет в полтора мега лежать в базе..

(27)а почему через веб сервисы а не через COM ?

(23) "типовые пишут вовсе не дураки.. и разрабатывают платформу в целом и БСП в частности отнюдь не идиоты"

Разные там попадаются... Вот например в ЗУПе сдельную оплату труда разрабатывал альтернативно одаренный товарищ..

(32) потому что документооборт через вебсервисы подключается в качестве внешнего источника файлов..

ну это если ты велокат не будешь изобретать...

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

так можно кодом его оптимизировать/автоматизировать, нафиг юзерам это гмно))

DjVu - если документы комбинированные - состоят из картинок и текста.

(34)а как лучше и взлетит у меня это?

(33) длинным по времени разработки и саппорта типовым - отдельныая беседа..
там накладываются костыли связанные с длительностью разработки и меняющимися условиями.. отчасти по этому выпускают абсолютно новые редакции - чисто чтобы обрубить костыли...

мы же сейчас про БСП говорим..

(38) у меня работа с хранением картонок в отдельной базе тормозила нещадно..

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

(39) "длинным по времени разработки и саппорта типовым - отдельныая беседа.. "
Тот идиотизм, о котором я сказал, появился не в результате длительного процесса разработки и внесения изменений, а сразу же. И не меняется. Я об отражении в бухучете сдельных нарядов ДО начисления зарплаты по ним..

А по поводу формата - дежавю конечно идеальный для рабочих сканов..

(41) фиг знает.. многие вещи пишутся криво по малоопытности с точки зрения методик..

может это один из примеров..

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

(42) только pdf

потому что следующей задачей будет задание воспользоваться сканами.. отправить клиенту или руководителю...

будешь всем рассылать дополнительно инструкцию где скачать программу для дежавю и как ее поставить на смартфон клиента ?

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

(45) Ничто не мешает написать внешнюю обработку, которая сохранит дежавю во временный каталог и конвертнет в pdf. Дело техники. Даже бинарник конвертера можно прямо в обработке хранить.. в макетах..

png - хорошо жмет, без потери качества, но размером больше jpg

(47) зачем ?
если есть стандарт который поддерживается всем..  в том числе и офисными МФУ которые сканят сразу в ПДФ и отправляют скан в почту...

http://lit999.narod.ru/images.html

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


а ради чего все это ?
какой смысл?
где экономия ресурсов и повышение надежности достигается?

(49) Для экономии места. PDF вообще-то не предназначен для сканов - это формат для оригинал-макетов документов, а не для копий.

(52) экономия простите какого места, где ?

(53) Экономия места в базе.

(25) Скл можно попросить сделать отдельный файл для таблиц с блобами картинок и хранить его там, где это нужно.

(47) Прикиньте вычислительные можности конвертатора из джв в пдф перед просмотром для пары десятков одновременных просмотров.

(54) то есть я правильно понимаю

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

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

(56) Зачем постоянно конвертить в pdf? Кому надо смотреть - установят смотрелку. Для прочих это будет просто бинарный файл в базе.

(54) а если бы файлы были в томах достаточно было бы просто подключить новый том  :)

(57) Зато это гарантирует, что dt-шка или sql-бэкап содержит ВСЕ данные.

(58) а есть примеры выигрыша в объеме файла между одинаковой картинкой в пдф и дежавю ?

о каких процентах разницы в размере файла идет речь ?

(50) в статье есть еще интересная инфа:

FIF -- Genuine Fractals
Компания Altamira Group хочет, чтобы вы перестали отправлять 100-Мбайт изображения для высококачественного вывода по почте или с курьером, а начали пересылать их по электронным каналам. Как? Компания заявляет, что разработанный ею дополнительный модуль Genuine Fractals может сжимать полученные в результате сканирования 25 Мбайт до 2 Мбайт, а затем "разворачивать" их для вывода на устройство с любым разрешением без потери качества.

Эта "волшебная" технология реализуется следующим образом: сначала идентифицируются все группы цветов и текстур в изображении, а затем они описываются не пикселами, а математическими фракталами. Мне кажется, что, называя Фрактальный формат изображения (Fractal Image Format, FIF) "независимым от разрешения", компания Altamira вводит нас в заблуждение, поскольку фрактальные данные по определению не могут содержать больше информации, чем исходные сканированные пикселы, но можно сказать, что FIF не зависит непосредственно от пикселов изображения.

При тестировании этот дополнительный модуль очень хорошо справлялся с увеличением изображений, причем без размытия контуров (недостаток, который проявляется при выполнении бикубической интерполяции в пакете Photoshop). Но у меня проявились некоторые недостатки при увеличении в два раза и более -- "крадратичность". Для сжатия и распаковки файлов FIF требуется некоторое время (в несколько раз большеe, чем для аналогичных операций над файлами JPEG для сжатия, а для распаковки очнь даже небольшое время), но для тех, кто стремится сократить время передачи файлов и не беспокоиться по поводу разрешения при выводе окончательных версий изображений, модуль Genuine Fractals может оказаться просто незаменимым средством. Существуют опции уменьшения размера файла за счет качества. При этом изображение приобретает "подчерк" импрессиониста. В некоторых случаях это можно назвать художественным эффектом. Существуют модули для просмотра таких картинок в Сети.

LuraWave -- Интересная разработка немецких(?) программистов для хорошего и отличного сжатия цветных и черно-белых изображений. Этот формат пока еще набирает обороты, но уже сейчас существуют плагины для Коммуникатора и Обозревателя интернета, Cumulus, Adobe Photoshop. Уже появилась программа просмотра InfanView, которая наравне с GIF, JPEG и прочими форматами поддерживает .LWF-формат. У меня этот формат позволял реально достичь коэффициента сжатия 25-30 при тех же потерях качества как у JPG при коэффициенте 10 (иными словами LWF меньше JPG в 2.5 раза). При увеличении коэффициента сжатия не проступает "квадратичность" как у JPEG. Вместо этого как бы накладывается фильтр SmartBlur, правда в некоторых областях имеются точки, которых "выпадают" из фона. Вместе с тем, качество всеравно выше, чем у JPEG.

Дальнейшее развитие данного формата вылилось в создание формата Jpeg2000 (j2k, jp2). По некоторым тестам Jpeg2000 немного превосходил LWF по качеству при том же размере файла. J2k изображения могут просматриваться MSIE только после закачки соответствующего плагина. При этом я наблюдал, как фотографии сохраненные при помощи ThumbsPlus в j2k формате не открываются в Adobe Photoshop (для которого тоже необходимо отдельно качать plugin). На заре появления этого формата обещалось, что цифровые фотоаппараты смогут сохранять фотографии в этом современном формате. Прошло почти 5 лет, а воз и ныне там - я не видел ни одного фотоаппарата, который смог бы записывать jpeg2000. Возможно производителей останавливает то, что для этого формата нужно на порядок больше вычислительных ресурсов, чем для JPG.

(60) а кому это надо и для чего ?
и что мешает отдельно файловыми средствами бекапить файловый архив и отдельно бекапить дт ?

в конце концов технически проще настроить бекап скулем который помимо фулбекапа будет делать еще рар файл с файловыми томами..

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

(61) Дежавю это формат, специально разработанный для сканов документов. Они использует хитрые алгоритмы сжатия специально для этой цели. Размер скана страницы а4 при сохранении читаемости может составит десяток килобайт. PDF же как формат вообще ничего не говорит о сжатии - это контейнер, в котором могут быть текстовые, векторные и растровые данные. Набор видов этих данных зависит от версии формата, начиная с какого-то момента появилаь графика со сжатием jpeg. А jpeg - это не лучший вариант для сканов, это формат для фотографий.. и сильно сжать текстовую печатную информацию он не может.

пример из личной практики:

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

базу выдают на руки.
типа бери и привози потом готовый вариант.

dtшка весит 7 гигов.
ибо в ней все файлы.


вынес файлы в тома.
dtшка весит 300 мегабайт.

(64) практические примеры можно ?

типа вот у меня 150 дипиай в пдф и вот у меня 150 дипиай в дежавю


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

(66) опечатался - сразу в пдфе отправляли..

(67)а что скажете если установлю 1С документооборот. и в нём будут храниться картинки но используя именно Тома, но из своей базы буду обращаться к документообороту через веб сервисы ? или же в этой цепочке документооборот будет лишним звеном?

(68) там узкое место именно вебсервис..
пофиг где сам документооборот хранит.. вебсервис все портит.

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

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

(70)а с веб сервисами в чем подводные камни?
и какой документооборот выбрать Проф достаточно или Корп ?

(72) корп конечно. С него откат больше получится

(73)а почему?

(72) у меня работало крайне медленно.. может я конечно что не докрутил но в итоге плюнул и выключил из базы этот функционал.

по поводу версий - тут вопрос в том для чего использовать будешь. глянь на сайте 1Са сравнение версий.. вроде если только для файлов то любой.

кстати - можно даже демобазу от платформы вроде использовать - там тоже этот вебсервис был :)

(74) потому что стоит дороже :)

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

(77) прикрути файлы из БСП к своей нетленке и храни с их помощью все в томах

(78)так к нетленке прикрепить или к основной базе? у нас основная база - это УТ10.3 + CRM

(79) вот где тебе нужны эти сканы, в туда и прикрути

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

я бы в PNG хранил

(81) "ну так ведь картинки если не в SQL версии базы хранятся, а в томах, то будут дико тормозить"


кто тебе эту чушь сказал ?

ничего что для того чтобы работать с картинкой которая лежит в виде хранилища ее сначала 1С всегда на диск пишет ?

а тут бац - она уже записана :)

(83)вы мне скажите окончательное решение какое мне выбрать? просто прикрутить к своей УТ библиотеку стандартных подсистем и хранить картинки в томах? или базу-посредника создать и в ней развернуть хранение картинок в томах ?

(84) я бы прикрутил..

стоп. а разве в УТ нет своей системы хранения прикрепленных файлов ?

Это прекрасно:

"вы мне скажите окончательное решение какое мне выбрать?"

http://prophotos-ru.livejournal.com/1628769.html

Каждый пользователь всемирной сети Facebook, кто хоть раз загружал туда свои фотографии, наверняка замечал, что изображение, попадая на сайт социальной сети, вдруг теряло в качестве. Разобраться с этой проблемой решила компания Google, разработавшая специальный формат WebP, позиционирующийся как формат для интернета. Размер картинок в нём на 26% меньше, чем в PNG и на 25-34% меньшем, чем в расхожем JPG. На сайте разработчика можно ознакомиться с небольшой сравнительной галереей JPG и WebP.

Facebook начал тестировать новый графический формат, отображая часть изображений в формате WebP. Загруженные пользователями фотографии из JPEG автоматически конвертируются в WebP, но отображаются в этом формате только в совместимых браузерах — Chrome и Opera.

Можно преобразовать изображение, уже опубликованное в Facebook, в формат WebP и самостоятельно. Так, в Chrome для этого нужно открыть изображение в новой вкладке и изменить jpg на webp в URL.

С помощью WebP компания Google рассчитывает значительно увеличить скорость просмотра веб-страниц и снизить нагрузку на Всемирную паутину. Однако, новый формат сразу же приобрел противников. Оказалось, что сохранив снимок себе на компьютер, его просто так не просмотришь и не откроешь в Photoshop без установки специальных плагинов.

(86)ну выберу на самом деле я сам. просто я запутался слегка. и уточняю теперь
(85)есть система хранения в ут это безусловно, но она хранит их в справочнике в реквизите типа "хранилище"

(88)если объем небольшой - я бы забил и юзал типовой механизм.
если объем большой планируется - прикрутил бы подсистему из БСП и вынес все в тома

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

(89)спасибо за четкий ответ. потому что планируется большой объем. только про веб сервис не совсем понял. если просто БСП прикрутить, то веб сервис уже не придется юзать?

(90) подключи и посмотри.. в чем проблема то ?

(91) нет не придется..

(93)реализую два варианта. сначала через БСП потом через подключение 1с документооборот. и проверю какое будет больше нравиться начальству.

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

В то время как в простом файловом варианте 1с для размещения документов просто не нужна. Оператор может насканить 100 страниц и простым F5 отправить в нужный каталог на диске. Хотя и тут не все просто.. приходится городить огород с идентификаторами договоров 1с.

(95) неудобно ибо велокат.

выкури БСП и сразу станет удобно..

+(96) и для тех кто тупой и ленится читать:

ДА!
в 1С работает перетаскивание..
то есть можно взять мышкой папку где лежат 50 гигов файлов в хитрых структурах и перетянув ее в форму списка справочника "файлы" в нужную папку автоматом ВСЕ 50 гигов загрузить в базу 1С

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