Где лучше хранить прикрепленные файлы в базе 1c (MSSQL) или в файлах на сервере?

На производительность чего?

я бы в базе хранил.
Бекапить удобней.

Влияет на бэкапы. 100 гигов бэкапить каждый день, или 20.

Храню в отдельно базе МС Скуля. И основную базу бакапить просто и базу с файлами бакапить тоже ничего.

(3) А, типа, если файлы не в базе лежат - то их бэкапить не надо?

(1), всего. Запись, проведение документов, формирование отчетов и т.д. MSSQL пофиг работать с файлом 10 гиг или 100?

(6) сам-то как думаешь? а еще в MSSQL на кой-то файловые группы придумали.

Нет однозначного ответа на твой вопрос.

(7) до первой реструктуризации?

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

(9) Если бы 1с этим занималась напрямую - то да, скорее всего это бы поломалось при очередном обновлении платформы :)

дада, хранить в базе будете до первой срочной выгрузке\загрузке данных.

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

(0) У меня порядка 20 Гб файлов в базе. Производительность пока не страдает. НО есть одно и наверное самое главное НО.
Это Выгрзка/Бекап - размеры не реальные.
На мисте много было терок по этой теме. Уважаемые люди советуют переносить на файловый сервер и дергать от туда с доступом только для 1 юзера. Повысит скорость обращения к файлам, и скорость работы с БД. При грамотном администрировании все будет ОК.

(3) о_О А если заюзать diff и log бекапы - гораздо меньше места потребуется

Если файлики мелкие - самое то хранить их в базе. Я так в ЗУП2.5 храню помесячные логи электронной проходной, в привязке к физлицу.

(12), 5 минут выгрузка/загрузка через SQL

(7) Размер таблицы (количество строк) имеет значение, но никак не размер базы

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

(10) проведение-то не пострадает, а вот бизнес процесс может встать колом и проводить будет тупо нечего.
Много файлов в базе - это:
1. Реструктуризация таблицы, содержащей блобы, будет в пределе очень долгой И есть риск, что когда-нибудь она тупо не закончится
2. Бэкап будет всегда содержать эти файлы, соответственно, подготовка тестовой зоны рано или поздно станет веселым занятием с поиском, чего бы такого грохнуть ,чтобы бэкап развернуть

Но это все так или иначе решаемо и однозначно на (0) не ответишь вот так с разбегу, не зная специфику и все имеющиеся требования и ограничения.

У меня 20-гигов файлов- летает.

(21) Файлы не в информационной базе)

Я считаю, что в базе надо хранить ссылки с путями и имена файлов. А если помойка критична бэкап средства в помощь

(21) 200 ГБ вложений (файлов) в базе -- всё норм, хоть терабайтами, на скорость работы базы это не влияет.

Единственный косяк описан в (20)
>подготовка тестовой зоны рано или поздно станет веселым занятием

Мы обычно бекап восстанавливаем в "транзитную" базу. Там делаем truncate+shrink. Потом опять бекапим, и из полученного бекапа готовим тестовые зоны, базы для разработки. Все это естественно автоматизированно. Сильно не плачем)
Но лучше все равно хранить файлы на диске, а критичные файлы в базе.

(0) можете в другой SQL базе.