Vofka @ Сегодня, 13:08 ,
Хорошо, надеюсь, что Вы в курсе, что кода в программном коде Вы обращаетесь к реквизиту справочника Номенклатура через точку, то считывается весь объект, вместе с основным изображением. Хотите увеличить траффик - имеете право, ввиду того, что у топик-стартера что-то из УТ2.3 или УТП или УПП, то код будет выполняться в толстом клиенте и фактически нужно будет донести эти мегабайты до компьютера пользователя.

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

Какая связь между "дублированием сущностей" и "несколько ГБ" места в БД? Картинки в БД это дубли чего? - ну в MS SQL важным файлом является файл транзакций, если в него напихать картинок, то он увеличится размерах, при этом для всех версий будет храниться это изображение.

А какие проблемы с этим были? - база тупо стала тормозить. После того как просто убрал картинки и файлы, ситуация существенно улучшилась

Vofka @ Сегодня, 8:48 ,

Выскажу свое мнение.
Если прикрепленных файлов уже 5-10 Гб и они хранятся в Базе, то на эти же 5-10 Гб увеличиваются все архивы Базы и копии Базы. Если места дофига и База одна и копия Базы для разработки тоже одна, то проблем нет, но в какой-то момент место начинает заканчиваться. А для разработки, как правило, файлы не нужны
Хотя, есть и обратная сторона медали: возможные разборки из серии "кто удалил мой любимый файл?". Но я с таким не сталкивался

В общем-то, если файлов немного, то хранить их в Базе, конечно, удобнее. Но, начиная с некоторого объема (я бы сказал, 5Гб), они начинают раздражать

А, да, еще был случай. Вендоры что-то изменили в системе хранения файлов в каком-то жестком обновлении. И tmp файл при реорганизации начал резко отжирать память, поскольку все прикрепленные файлы пошли в него. Пришлось плясать с бубном. Если я не ошибаюсь, это было при переходе ЕРП 2.1 -> 2.5

я сталкивался
именно в такой вот интерпретации
и последующие претензии в стиле, "а как это могло удалиться, это же база?" (объяснения, что это НЕ база, не помогают -- "а вот мы там (в файле) сохранили важную информацию, где она?")
сюда же проблемы с отслеживанием, кто чего изменил и поиском того, кто это удалил


как вариант -- хранить всякий такой мусор в подчиненном справочнике

хотя, конечно, толстый клиент -- вчерашний день
(по правде говоря, лично я, так уж вышло, 8.0 - 8.2 благополучно пропустил, у меня было так: 1999 - 2017 (7.7 и все такое в стиле rainbow/1с++, даже еще в 99м немного застал 7.5), 2017 -- поныне (8.3, уф))

то, что спiлка снова выкатила в продажу 1С УТП под видом БАС УТП, говорит о многом

В курсе не только лишь я, а и разработчики типовых конфигураций, которые еще 100 лет назад вынесли картинки из основных справочников в отдельные справочники.


И разве ж это "легче работать и обслуживать"?


А как БСП справляется, например, с доступом к внешнему каталогу файлов, в зависимости от RLS или каких-то настроек, типа "Васе можно редактировать картинки из группы Крупы, а Пете из группы Овощи"? Ответ

Никак. БСП может контролировать что-то для доступка к справочнику с номенклатурой, но никак не к внешней папке на диске

Если что, то файл транзакций не всегда как бы есть. Точнее говоря, он может быть есть всегда, но при правильной модели восстановления его размер не растет. В мире 1С (та и не в мире 1С) это очень редкие случаи, когда действительно надо иметь файл транзакций. Это штука, про которую кто-то где-то слышал, но мало кто понимает что это, зачем и как этим пользоваться. Но на всякий случай "хай буде". Если у вас БД на 10-20 Гб, я очень сильно сомневаюсь, что вам это надо. И последнее. Бинарные данные в лог не пишутся как есть, там они пишутся в специальном каком-то формате, что означает, что картинка на 1 Мб это не +1 Мб в лог транзакций.

Со своего опыта вы можете сказать зачем вам БД с пишушимся файлом транзакций? Чтобы что? Только не из теоретической плоскости, а из практической, желательно с примером того, какую проблему вы решили этим.


Т.е. проведение документов тупило, отчеты тупили, а потом после удаления картинок, перестали тупить? Вам самому это не странно звучит?


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

Vofka @ Сегодня, 14:16 ,
Вам хочется поспорить?

В курсе не только лишь я, а и разработчики типовых конфигураций, которые еще 100 лет назад вынесли картинки из основных справочников в отдельные справочники. - Топикстартер привел код для УТ/УТП/УПП. Там основное изображение - реквизит справочника и имеет тип Хранилище значений. Я давал свои рекомендации касательно этого вида конфигураций, и обсуждать имеются ли в каких-то конфигурациях отдельные справочники для хранения чего-то считаю бессмысленным

И разве ж это "легче работать и обслуживать"? - да, база стала существенно меньше в размерах, стала легче открываться, как только все бинарные файлы были выгружены из нее. Есть золотое правило механики, но оно прекрасно работает и в других областях. Я выиграл в быстродействии, в том. что MS SQL перестал выбирать всю память на сервере, люди смогли для нужд интернет-магазина хранить по несколько картинок при 20к позиций в справочнике Номенклатуры.

А как БСП справляется, например, с доступом к внешнему каталогу файлов, в зависимости от RLS или каких-то настроек, типа "Васе можно редактировать картинки из группы Крупы, а Пете из группы Овощи"? - практически точно так же как и обычные формы. прямого доступа к диску нет ни у кого из пользователей, то есть можно добавлять/изменять/удалять только через карточку Номенклатуры, а здесь РЛС можно настроить

Со своего опыта вы можете сказать зачем вам БД с пишушимся файлом транзакций? Чтобы что? Только не из теоретической плоскости, а из практической, желательно с примером того, какую проблему вы решили этим. - я практикующий программист 1с, по настройке серверов БД посмотрел несколько курсов, но по большей части, чтобы объяснить администраторам что я хочу, чтобы не просить невозможного. Знаю, что данный файл по умолчанию есть, знаю, что он нужен для восстановления данных в результате сбоев. Я не хочу особо вникать в детали, иначе нужно менять профессию. Практический пример не приведу, но на курсах вроде рассказывалась возможность отката до определенной операции, сами понимаете, что если база достаточно большая, то восстановление из бэкапа может быть достаточно продолжительной операцией и потом перебивать данные с момента бэкапа. Даже если Вы настроили бэкап каждый час, то с большой долей вероятности потеряете несколько часов на восстановление и повторное введение информации.

Т.е. проведение документов тупило, отчеты тупили, а потом после удаления картинок, перестали тупить? Вам самому это не странно звучит? - Я про проведение документов ничего не писал и про формирование отчетов вроде ни слова не было, просто само открытие базы стало происходить существенно быстрее. В этот момент, насколько я помню, происходит считывание кэша, в котором могут находиться наиболее часто используемые данные. Если менеджеры по продажам/закупкам в основном работают со справочником номенклатуры, то вполне возможно, что там хранятся и какие-то данные. Еще один момент, зачастую франчайзи включают версионирование объектов. Это тоже кандидат на увеличение размеров базы, и там по умолчанию в типе объекта стоит любой справочник и документ.

Можно заставлять клиента докупать память на сервер или менять железо, и я сталкивался с такими случаями, а можно попробовать сделать так, чтобы база продолжала работать с нормальным быстродействием. Клиенты сейчас не супербогатые, так что если деньги уйдут на покупку железа, то мне заказов не будет, так что я стараюсь больше для себя. Но никого не заставляю. Каждый сам себе выбирает путь.

С вами? Боже упаси. Вопросов больше нет. Извините.

Сообщение отредактировал Vofka - 02.06.25, 8:16