Вставлю и я свои две копейки. Вообще, данный вопрос, как и все прочие, надо рассматривать в контексте задачи и применяемых инструментов. Если рассуждать абстрактно-субъективно, то я сторонник хранения файлов в файловой системе, а не в БД. Основных причин тому несколько.

1. Удобство сопровождения / администрирования. Мало приятного возиться с блобами в стандартных админских тулзах типа ms sql enterprise manager, IBExpert и иже с ними.

2. Индексирование содержимого файлов. Не все серверы БД умеют это хорошо делать. Я понимаю, что тут речь про ms sql у которого, вероятно, с этим все хорошо. Но есть, например, Firebird и прочие, у которых с этим вообще никак. Зато есть сторонние продукты, типа встроенного в винду Indexing Service или локального Google и т.д., которые с задачей индексирования и поиска файлов разных форматов справляются на ура. А состыковать их с сервером БД - дело техники.

3. Открывает файлы из БД и складывает их туда, как правило, пользователь со своей рабочей станции. А там, в большинстве случаев, винда и ее приложения. В случае хранения файлов в БД придется как-то описывать, что же там за файл внутри и чем его открывать. И где это нечто брать на клиентской машине. В конечном итоге получим и проблему "Save as...", которая описывалась по приведенной тут ссылке, и проблему сохранения временного файла на локальной машине пользователя. При хранении на сервере в файловой системе не сильно сложно реализовать открытие файла прямо с него родимого командой "start ИмяДокумента" - и пускай винда сама разбирается, что там ей подсунули и чем это открыть. (соглашусь, что такое поведение можно эмулировать и при хранении файлов в БД, но, как говорится, "нафига козе баян" или зачем усложнять себе жизнь). Кстати, и проблемы просмотра любимого 5GB видеоролика не возникнет - все уже написано за нас. :)

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

В общем, базе - базово, а файловой системе - файлово. :)

ПрограммиздищеСреднее звено должно обеспечивать передачу файла туда и обратно, не прибегая ни к каким шарам.не очень понятно, как это возможно без шар, в общем случае? точнее, что это будет за среднее звено, которое подсунуло ворду файл (и куда подсунуло, кстати? во временный каталог на клиенте?), а затем, когда пользователь нажал "save", сохранило его куда надо в бд. а если это не ворд, а фотошоп / корел / акробат / ... ? будем в среднем звене держать на каждое такое пользовательское приложение свою поддержку?

похоже, я безнадежно отстал от жизни и чего-то не знаю в современных технологиях? :)

ПрограммиздищеХотелось бы продолжить разговор с точки зрения путейца, т.е. если используется хранение в файловой системе по конкретным путя/путю, то как рациональнее? Или может назначит одну папку для хранения файлов и не заморачиваться? Или создать ограниченное их количество по типам лежащих там файлов, скажем /DOC/, /XLS/, /TXT/ ?мы храним по-простому: есть одна папка, назовем ее file-storage, а в ней на каждый файл заводится своя папка с именем, совпадающим с id-файла, который (id) используется в бд для привязки данного файла к прочим объектам. в этой id-папке лежит файл с тем оригинальным именем, которое было задано пользователем.

что-то наверное спать пора - нет четкости фраз, путанно изъясняюсь уже... :)

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

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