Хранить или лучше не хранить сканы Договоров в Хранилище значений?

Лучше не хранить.

У нас сейчас договора хранятся в специальном каталоге на сервере, не в базе данных. Делалось давно, не нашей командой. Почему так сделано, могу только предположить. Полагаю, чтобы не увеличивать размер базы. На данный момент этот каталог занимает 35 Гб. Я лично не считаю, что это очень много и что это как-то будет влиять на производительность системы. Если ещё сделать по уму - то тем более. А вот минус этого дела таков, что случались жалобы от пользователя, мол раньше был скан договора у клиента, а сейчас нету. Смотрим, файла на сервере нету. Был он там или нет - фиг знает. И если, например, база куда-то переезжает, то надо не забывать таскать за собой этот каталог.


Почему?

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

в правах на папку убрать галку "Удаление", и проблема решена.

Встречалась мне база на 18 гб файловая, в неё загружались скан копии сертификатов продукции, на каждую партию. Летала на ура, даже не притормаживала. Я бы хранил вне базы, объяснить затрудняюсь, но что-то мне стрёмно такой объем лить в базу. Кстати, старые сертификаты в базе можно и удалить, а старые договора вряд ли...

Acid @ Сегодня, 14:01 необходимо зарегистрироваться для просмотра ссылки,
Та же проблема стоит, только с чертежами и дизайн-макетами.
Склоняюсь к внешнему хранению, а в базе только линки (импорт в каталог через рубрикатор с преобразованием имени файла.).
Почему?

За счет чего?


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


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


За счет чего? Дольше файлик куда-то копироваться будет? Ну так каталог тоже, если что, перемещать нужно.


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

Короче говоря, я лично, не могу принять не одного из аргументов выше.


Удалять тоже надо иметь возможность, если что .

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

Если линковать, то такой каталог в конечном итоге станет файло-помойкой. хрен там что найдешь. Строить структуру каталогов, другое дело.
Это будут и Сертификаты, и Договора, и прочие сопутствующие документы. Объем получится не слабый.
Хранить в базе меня останавливает следующий момент - если база "сбойнет", то фиг восстановишь. Потому что хранится в сжатом виде и в двоичных данных.
В обоих методах по плюсам/минусам практически паритет.
Чешу репу...

Страховиков никто не обслуживает? как там реализовано?


Историю надо хранить. Переместить в папку "Устаревшие", например.

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


А то, что кроме сканов договоров будет ещё и куча другой информации потеряно - это не проблема?


Наверное. Но это все организовывать как-то надо. Мы, 1С-ники, хотим просто заходить в журнал регистрации и смотреть кто что менял.

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

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

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

В данном случае у нас, например, организовано так: отдельный сервер БД, отдельный файловый сервер. Именно это и имел ввиду.

Например, перенос базы по любой причине (переезд, копирование для тестирования, резервирование, хранение резервных копий ...). Проще и быстрее работать с 10 гиг, чем с 100.

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

За счет какого манипулирования? Можете привести конкретный пример о чем речь, потому что не понимаю.


Опять таки, не понятно. Приведите пример варианта использования, когда будет лучше.


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


С этим я согласен. Но. Вряд-ли соотношение сканов к остальной информации базе будет 90% на 10%. То есть, если база большая, то скорее всего сканы это не основной её объем. А посему будет ли реально какой-то действительный профит от копирования 100 Гб по сравнению пусть с 70 Гб? Как по мне, то профита особо никакого.

Если говорить о сжатых данных (резервное копирование средствами СУБД или выгрузка средствами 1с), то чаще всего это будет даже больше 90%.

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

Изящный пример сейчас не придумаю. Но хорошо уже то, что не требуются операции ни помещения, ни извлечения из хранилища при прочих равных условиях.

Здесь я говорю о том, что "цена" хранения единицы данных в СУБД выше "цены" хранения на диске за счет различных операций: перестроение индекса, проверка целостности бд, резервное копирование, сжатие бд... Но опять таки, это все в теории...

Это можно посчитать, взять количество заключённых договоров за год с "додатками" и "протоколами розбіжностей" и умножить на среднюю длину договора в страницах А4 и умножить на размер скана страницы в 1,2Мб (jpg среднего качества). Узнаете рост базы в год, и умножите на количество лет сопровождения базы без сворачивания в архив.
По нашим расчётам, средний договор без больших дизайн-макетов - 25Мб. Но у нас есть проблема дорогого рейда из SAS 15k, который не хочется использовать для "мёртвых" данных в 17% от общего размера базы (ведь договоры нужны редко для просмотра и печати, а ещё надо умножить на 3, так как есть две копии базы для разработчиков внутренних и франча).
Я всё больше склоняюсь к внешнему хранению.

andr_andrey, с такой вводной, как у вас - возможно. Но справедливости ради стоит отметить, что можно секционировать базу на уровне SQLя и вынести соответствующую таблицу на отдельный носитель.

О! вот это дельное решение.

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


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


Тогда я приведу 2 примера:
1) 1 секунда и 100 секунд
2) 0.00001 секунда и 0.0000001
В обоих примерах разница между временем составляет 2 порядка. 2 порядка - это относительно много? Конечно. А абсолютно? А если абсолютно, то в первом случае это много, а во втором - это ерунда. Хотя, еще раз, и там и там разница в 2 порядка. Так вот, то о чем вы говорите про извлечение и помещение в хранилище, на мой взгляд, это больше приближено ко второму случаю, чем к первому.

Когда ваша база достигнет 100 Гб. То вы поймете, что изображения надо хранить только в файлах, а в базе только ссылки на файлы.

100 Гб? Не напугали. Ну и т.к. никакой конкретики, то звучит не убедительно.

еще один теоретик...не очень серьезный.

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

часто ли сканы запрашивают, с какой целью, что посмотреть ?

еще , кто-нибудь пробовал съесть слона? кто-нибудь пробовал хранить в интернете?

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

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

можно ж и отдельно завести нулевую базу под договора, продублировав эл. номера из первой базы.

Если договоров реально много - лучше не хранить