Версия для печати темы (https://pro1c.org.ua/index.php?showtopic=28754)

Автор: Vofka 17.03.16, 16:42

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


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


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

Автор: andr_andrey 17.03.16, 16:48

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

Автор: Acid 17.03.16, 16:54

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

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

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

Автор: Vofka 17.03.16, 17:00

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

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

Автор: Petre 17.03.16, 17:24

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

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

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

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

Автор: Vofka 17.03.16, 17:42

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


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

Автор: Petre 17.03.16, 18:09

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

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

Автор: andr_andrey 17.03.16, 18:14

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

Автор: Vofka 18.03.16, 10:57

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

Автор: Acid 18.03.16, 11:25

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

Автор: Vofka 18.03.16, 11:57

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

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

Автор: gorak 18.03.16, 14:12

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

Автор: Vofka 18.03.16, 14:24

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

Автор: Домовик 18.03.16, 16:38

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

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

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

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

Автор: Vofka 18.03.16, 17:25

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

Автор: pablo 18.03.16, 18:05

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

Автор: Домовик 20.03.16, 7:11

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

Автор: Галина Ігорівна 13.02.17, 19:17

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