Заказы на доработку 1С (сервис удаленной работы)

Хранилище

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

Здравствуйте, гость ( Вход | Зарегистрироваться )



> нужен совет по Договорам 2 страниц V   1 2 >          
Acid Подменю пользователя
сообщение 17.03.16, 14:01
Сообщение #1

Про1С-ник
Иконка группы
За заслуги на форуме в 2010 году
Группа: Местный
Сообщений: 2104
Из: Занзибар
Спасибо сказали: 377 раз
Рейтинг: 260.7

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

Petre Подменю пользователя
сообщение 17.03.16, 14:07
Сообщение #2

Живет на форуме
Иконка группы
Группа: Местный
Сообщений: 2902
Из: Київ, Україна
Спасибо сказали: 1144 раз
Рейтинг: 1225

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


Signature
Допрацьовую:
- "Бухгалтерія для України 2.1";
- "Альфа-Авто: Автосалон+Автосервіс+Автозапчастини, українська версія".

Vofka Подменю пользователя
сообщение 17.03.16, 14:26
Сообщение #3

У нас здесь своя атмосфера...
***********
Группа: Основатель
Сообщений: 13948
Из: Киев
Спасибо сказали: 4514 раз
Рейтинг: 3635.6

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

Цитата(Petre @ 17.03.16, 14:07) *
Лучше не хранить.

Почему?

Petre Подменю пользователя
сообщение 17.03.16, 14:41
Сообщение #4

Живет на форуме
Иконка группы
Группа: Местный
Сообщений: 2902
Из: Київ, Україна
Спасибо сказали: 1144 раз
Рейтинг: 1225

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


Signature
Допрацьовую:
- "Бухгалтерія для України 2.1";
- "Альфа-Авто: Автосалон+Автосервіс+Автозапчастини, українська версія".

Acid Подменю пользователя
сообщение 17.03.16, 15:12
Сообщение #5

Про1С-ник
Иконка группы
За заслуги на форуме в 2010 году
Группа: Местный
Сообщений: 2104
Из: Занзибар
Спасибо сказали: 377 раз
Рейтинг: 260.7

Цитата(Petre @ 17.03.16, 14:07) *
А вот минус этого дела таков, что случались жалобы от пользователя, мол раньше был скан договора у клиента, а сейчас нету. Смотрим, файла на сервере нету. Был он там или нет - фиг знает.

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


Signature

Документируйте Код! мать вашу...


Егор Динин Подменю пользователя
сообщение 17.03.16, 15:38
Сообщение #6

Почти крутой
Иконка группы
Группа: Местный
Сообщений: 1454
Из: Киев
Спасибо сказали: 548 раз
Рейтинг: 0

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

andr_andrey Подменю пользователя
сообщение 17.03.16, 16:39
Сообщение #7

Почти ветеран
Иконка группы
Группа: Местный
Сообщений: 623
Спасибо сказали: 166 раз
Рейтинг: 130.8

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


Signature
#define private public
enum BOOL { FALSE, TRUE, FILENOTFOUND } is made my day

Vofka Подменю пользователя
сообщение 17.03.16, 16:42
Сообщение #8

У нас здесь своя атмосфера...
***********
Группа: Основатель
Сообщений: 13948
Из: Киев
Спасибо сказали: 4514 раз
Рейтинг: 3635.6

Цитата(Petre @ 17.03.16, 14:41) *
Из-за уменьшения производительности сервера базы данных

За счет чего?

Цитата(Petre @ 17.03.16, 14:41) *
производительности программы (надо и помещать, и извлекать)

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

Цитата(Petre @ 17.03.16, 14:41) *
понижения показателей целостности и сохранности (в случае сбоя, например)

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

Цитата(Petre @ 17.03.16, 14:41) *
ухудшения мобильности

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

Цитата(Petre @ 17.03.16, 14:41) *
повышения сложности администрирования

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

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

Цитата(Acid @ 17.03.16, 15:12) *
в правах на папку убрать галку "Удаление", и проблема решена.

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

andr_andrey Подменю пользователя
сообщение 17.03.16, 16:48
Сообщение #9

Почти ветеран
Иконка группы
Группа: Местный
Сообщений: 623
Спасибо сказали: 166 раз
Рейтинг: 130.8

Цитата(Vofka @ 17.03.16, 16:41) *
А помещать с сервера на клиент и извлекать обратно, в случае с файловым каталогом, не надо что ли?
...
За счет чего? Дольше файлик куда-то копироваться будет? Ну так каталог тоже, если что, перемещать нужно.


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


Signature
#define private public
enum BOOL { FALSE, TRUE, FILENOTFOUND } is made my day

Acid Подменю пользователя
сообщение 17.03.16, 16:54
Сообщение #10

Про1С-ник
Иконка группы
За заслуги на форуме в 2010 году
Группа: Местный
Сообщений: 2104
Из: Занзибар
Спасибо сказали: 377 раз
Рейтинг: 260.7

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

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

Цитата(Vofka @ 17.03.16, 16:42) *
Удалять тоже надо иметь возможность, если что

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


Signature

Документируйте Код! мать вашу...


Vofka Подменю пользователя
сообщение 17.03.16, 17:00
Сообщение #11

У нас здесь своя атмосфера...
***********
Группа: Основатель
Сообщений: 13948
Из: Киев
Спасибо сказали: 4514 раз
Рейтинг: 3635.6

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

Цитата(Acid @ 17.03.16, 16:54) *
Хранить в базе меня останавливает следующий момент - если база "сбойнет", то фиг восстановишь.

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

Цитата(Acid @ 17.03.16, 16:54) *
Историю надо хранить. Переместить в папку "Устаревшие", например.

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

Petre Подменю пользователя
сообщение 17.03.16, 17:24
Сообщение #12

Живет на форуме
Иконка группы
Группа: Местный
Сообщений: 2902
Из: Київ, Україна
Спасибо сказали: 1144 раз
Рейтинг: 1225

Цитата(Vofka @ 17.03.16, 16:42) *
За счет чего?

За счет манипулирования избыточными данными. Ведь, по-сути, нам не нужны ни итоги, ни статистика, ни индексация. Это просто двоичные данные, которые в момент их использования все равно превращаются в файлы.
Цитата(Vofka @ 17.03.16, 16:42) *
А помещать с сервера на клиент и извлекать обратно, в случае с файловым каталогом, не надо что ли?

В случае хранения в ИБ - надо в любом случае. В случае хранения как файлы - не всегда (зависит от варианта использования). Т.е. "хуже не будет, но может быть лучше")))
Цитата(Vofka @ 17.03.16, 16:42) *
Опять таки, не обижайтесь, но как по мне, это аргумент высосан из пальца. То же самое можно сказать про файловую систему. Кстати, про то, что надо делать регулярные бэкапы базы - про это многие знают. В случае с файловым хранилищем нужно дополнительно организовать и мониторить и его бэкапы.

Согласитесь, когда к файловым операциям (которые тоже не стабильны) добавляются преобразования туда-обратно средствами 1с и сам способ хранения, то простым арифметическим перемножением условных коэффициентов нестабильности получаем меньший итоговый коэффициент, чем в варианте файлового хранения.
Цитата(Vofka @ 17.03.16, 16:42) *
За счет чего? Дольше файлик куда-то копироваться будет? Ну так каталог тоже, если что, перемещать нужно.

В данном случае у нас, например, организовано так: отдельный сервер БД, отдельный файловый сервер. Именно это и имел ввиду.
Цитата(Vofka @ 17.03.16, 16:42) *
За счет чего? Как по мне, то повышение сложности администрирования относится к минусам отдельного файлового каталога.

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

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


Signature
Допрацьовую:
- "Бухгалтерія для України 2.1";
- "Альфа-Авто: Автосалон+Автосервіс+Автозапчастини, українська версія".

Vofka Подменю пользователя
сообщение 17.03.16, 17:42
Сообщение #13

У нас здесь своя атмосфера...
***********
Группа: Основатель
Сообщений: 13948
Из: Киев
Спасибо сказали: 4514 раз
Рейтинг: 3635.6

Цитата(Petre @ 17.03.16, 17:24) *
За счет манипулирования избыточными данными. Ведь, по-сути, нам не нужны ни итоги, ни статистика, ни индексация. Это просто двоичные данные, которые в момент их использования все равно превращаются в файлы.

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

Цитата(Petre @ 17.03.16, 17:24) *
В случае хранения в ИБ - надо в любом случае. В случае хранения как файлы - не всегда (зависит от варианта использования)

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

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

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

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

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

Petre Подменю пользователя
сообщение 17.03.16, 18:09
Сообщение #14

Живет на форуме
Иконка группы
Группа: Местный
Сообщений: 2902
Из: Київ, Україна
Спасибо сказали: 1144 раз
Рейтинг: 1225

Цитата(Vofka @ 17.03.16, 17:42) *
Вряд-ли соотношение сканов к остальной информации базе будет 90% на 10%.

Если говорить о сжатых данных (резервное копирование средствами СУБД или выгрузка средствами 1с), то чаще всего это будет даже больше 90%.
Цитата(Vofka @ 17.03.16, 17:42) *
Но давайте смотреть на вещи реально, а не с точки зрения "теоретиков". Вы или кто-то из круга ваших знакомых программистов, когда-нибудь сталкивались с проблемой, когда были бы заметны проявления этой теории?

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

Изящный пример сейчас не придумаю. Но хорошо уже то, что не требуются операции ни помещения, ни извлечения из хранилища при прочих равных условиях.
Цитата(Vofka @ 17.03.16, 17:42) *
За счет какого манипулирования? Можете привести конкретный пример о чем речь, потому что не понимаю.

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

Сообщение отредактировал Petre - 17.03.16, 18:10


Signature
Допрацьовую:
- "Бухгалтерія для України 2.1";
- "Альфа-Авто: Автосалон+Автосервіс+Автозапчастини, українська версія".

andr_andrey Подменю пользователя
сообщение 17.03.16, 18:14
Сообщение #15

Почти ветеран
Иконка группы
Группа: Местный
Сообщений: 623
Спасибо сказали: 166 раз
Рейтинг: 130.8

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

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


Signature
#define private public
enum BOOL { FALSE, TRUE, FILENOTFOUND } is made my day

Vofka Подменю пользователя
сообщение 18.03.16, 10:57
Сообщение #16

У нас здесь своя атмосфера...
***********
Группа: Основатель
Сообщений: 13948
Из: Киев
Спасибо сказали: 4514 раз
Рейтинг: 3635.6

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

Спасибо сказали: Acid, Егор Динин,

Acid Подменю пользователя
сообщение 18.03.16, 11:25
Сообщение #17

Про1С-ник
Иконка группы
За заслуги на форуме в 2010 году
Группа: Местный
Сообщений: 2104
Из: Занзибар
Спасибо сказали: 377 раз
Рейтинг: 260.7

Цитата(Vofka @ 18.03.16, 10:57) *
Но справедливости ради стоит отметить, что можно секционировать базу на уровне SQLя и вынести соответствующую таблицу на отдельный носитель.

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


Signature

Документируйте Код! мать вашу...


Vofka Подменю пользователя
сообщение 18.03.16, 11:57
Сообщение #18

У нас здесь своя атмосфера...
***********
Группа: Основатель
Сообщений: 13948
Из: Киев
Спасибо сказали: 4514 раз
Рейтинг: 3635.6

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

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

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

Цитата(Petre @ 17.03.16, 18:09) *
Изящный пример сейчас не придумаю. Но хорошо уже то, что не требуются операции ни помещения, ни извлечения из хранилища при прочих равных условиях.

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

Цитата(Petre @ 17.03.16, 18:09) *
Но опять таки, это все в теории...

smile.gif

Сообщение отредактировал Vofka - 18.03.16, 11:59

gorak Подменю пользователя
сообщение 18.03.16, 14:12
Сообщение #19

Говорящий
***
Группа: Пользователи
Сообщений: 69
Из: Харьков
Спасибо сказали: 20 раз
Рейтинг: 0

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

Vofka Подменю пользователя
сообщение 18.03.16, 14:24
Сообщение #20

У нас здесь своя атмосфера...
***********
Группа: Основатель
Сообщений: 13948
Из: Киев
Спасибо сказали: 4514 раз
Рейтинг: 3635.6

Цитата(gorak @ 18.03.16, 14:12) *
Когда ваша база достигнет 100 Гб. То вы поймете, что изображения надо хранить только в файлах, а в базе только ссылки на файлы.

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

Не нашли ответа на свой вопрос?
Зарегистрируйтесь и задайте новый вопрос.


2 страниц V   1 2 >
Ответить Новая тема
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0

 

RSS Текстовая версия Сейчас: 28.03.24, 19:39
1С Предприятие 8.3, 1С Предприятие 8.2, 1С Предприятие 8.1, 1С Предприятие 8.0, 1С Предприятие 7.7, Литература 1С, Общие вопросы по администрированию 1С, Методическая поддержка 1С - всё в одном месте: на Украинском 1С форуме!