Ну чтобы клиент не видел путей, то тут уж точно БД - какое еще звено зачем приплетать.
Администрировать, бэкапить и т.д. точно лучше в БД.
Индексирование - ну тут разные возможности, в основном можно, про IB не говорим :)
Файл откроется сам - если великие проектировщики файловых приложений не знают, что в БД можно хранить расширение файла, при запросе файла юзером сохранить во временный файл на диске с таким же расширением и дернуть стандартный метод винды открытия файла соответствующим такому типу файлов приложением - тогда о чем разговор вообще?
При закрытии файла либо отслеживать это, либо явно жать кнопку сохранить файл.

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

-- Tygra's --
Мои фотогалереи тут

NSFuimus если уж остановишься на простом клиент-сервере (хотя вру - эта универсальный механизм) - введи в систему понятие "файловых шкафов" - в твоем случае это будут разные таблицы в БД ... соответсвенно ежедневные бэкапы необходимо нужно будет делать только с "активного" файлового шкафа ...
Бэкапы обычно со всей БД бэкапятся.
Это уж если хочется - да даже и нужно - делать отдельные БД по каким-то признакам. Годы, типы, отделы и т.д. Тогда и забыкапить легко будет, и поднять......

-- Tygra's --
Мои фотогалереи тут

NSFuimus Бэкапы обычно со всей БД бэкапятся.
"обычно" теряет всякий смысл когда идет речь о ежедневных бэкапах миллионов файлов "размером 0.1-80 Мб"
то уж если хочется - да даже и нужно - делать отдельные БД по каким-то признакам. Годы, типы, отделы и т.д. Тогда и забыкапить легко будет, и поднять......
я предложил самый простой и ненадуманный вариант бэкапа - включать в него родного только ту таблицу в которую загружают файлы ВСЕХ типов, ВСЕ отделы, в течение ВСЕГО времени определяемого и контролируемого администратором ... и тд и тп ... этот механизм вообщем-то де-факто ... придуман не мной ...
Это если у вас есть возможность забыкапить отдельно одну таблицу - валяйте.
А если нет - чего бэкапить будете?
Потому и лучше сразу разделять и структуру всего этого сразу прописывать.

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

-- Tygra's --
Мои фотогалереи тут

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

И так, определились - проблемы поиска по тексту и свойствам файлов у нас нет. Есть собственный классификатор для этих дел, который развивается в любую нужную сторону.
Есть задача - привязать договора к поставщикам (например).
Привязали. Храним файлы в БД.
Чего имеем из плюсов:
- легкое бэкапирование
- легкое манипулирование
- возможность простой репликации куда хочешь
- и самое главное, полная независимость от сетки : нам не нужны ни пути, смапленные на файловое хранилище, ни вечная проблема переноса-переименования-переконфигурации серверов, сети и т.д., ни вообще коннект к любому файл-серверу и т.п. Файлы всегда с нами в системе, даже если вы сидите через VPN, десять провайдеров или вообще на локальном IP - файлы тут, не нужен никакой путь никуда, вообще плевать, где и какая сеть. Это самое главное. И эта система расширяема в любые стороны на сколько хошь.

Минусов нет
Минусы только при размещении файлов в файловой системе. Одни минусы.

=========
Vadim Kruglikа давайте-ка для начала определимся, зачем нам вообще файлы в БД? :) ну то есть тупо переносить какую-либо иерархию файлов в базу, по аналогии со структурой каталогов на диске - на мой взгляд просто ни к чему (мягко говоря).
Выше все сказано
автор приведу пример: есть договор с поставщиком на тему свежих помидоров. кому-то из юзеров удобнее видеть документ в разделе "договоры с поставщиками", а кому-то - "договоры про помидоры" (извините за каламбур). :) но документ-то (или файл, если угодно) в обоих случаях один и тот же.
И причем тут БД?
автора средств борьбы с миллионами файлов на одном диске/разделе/каталоге на уровне той же ос windows server есть несколько - и линки на уровне ntfs, и dfs тот же, да и всякие софт/хард продукты третьих фирм пачками продаются наверняка (я давно не изучал сей вопрос).
А в случае с БД все уже решено, не надо никаких третьих фирм и т.д.
авторфайл в бд, фактически, нужен как некий блоб, для которого в бд хранятся атрибуты для разных целей (поиска, сортировки, группировки, выстраивания в разные иерархии и т. д.). хранить его в поле блоб или на диске - это вопрос различных удобств. на мой взгляд, хранение на диске более удобно (причины я описывал выше).
Файл нам нужен как файл.
А причин для фс я не нашел ни у кого - нашел только незнание возможностей СУБД.
авторкстати, всеми [не]любимый ms office (да и не только он, по-моему) имеет механизм атрибутов документов, встроенных в сам файл (document properties). засунув такой документ в блоб мы автоматически лишаем себя удовольствия поиска по таким атрибутам (думаю, что только у ms sql server есть такая возможность, если вообще есть).
Нам этих удовольствий и не надо. :))
авторлибо на каждый чих вытаскивать файл из блоба на диск и делать там с ним что-то. а ради чего? просто ради того, чтобы все лежало в n-томовом файле бд? честно, не понимаю.
Ради того, чтобы не было проблем, мной выше описанных (которыми не страдает БД).

Программиздище miksoftНе знаю, упоминали или нет еще один плюс хранения файлов в БД - возможность применения к данным встроенных механизмов СУБД. В частности - репликация, бэкап, управление правами доступа.
Это, конечно, реализуемо и в случае хранения файлов в ФС, но тогда придется использовать дополнительные интструменты и не всегда это легкореализуемо.
Такой подход обычно подвергают критике как недостаточно извращенный.
И обычно критикуют те, кто СУБД в глаза не видел.

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

-- Tygra's --
Мои фотогалереи тут