Хитрый Tsyklop хочет получить сразу ответы - но их нет. Более того - он не хочет отвечать
по нагрузке, размеру файлов и т.п. Это невежливо.

Эта задача - суть матрица стратегий.

Если ее нарисовать табличкой

Хранение файлов в файловой системеХранение файлов в БДУдальная стоимость хранения 1ГбПропускная способность (мб/сек)Наличие hot backup (и здесь можно написать еще около 100 пунктов)

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

Tsyklopне отвечаю ибо спрашиваю вообще, а не за конкретный проект.
Размер файлов любой.

И то если брать проект, то по началу нагрузки не будет ибо он будет развиваться, но потом возрастет. Это тоже надо учитывать.
Концептуально.

Любая реляционная БД (исторически) проектировалась как механизм обслуживающий
данные в таблицах в 1-2-3 НФ. И для того чтобы этот механизм работал эффективно
(buffer pool), надо чтобы атомы которые хранятся в таблицах были не очень большого
размера. 1-НФ кстати требует чтоб в ячейках лежали атомы. Можно-ли файл считать
атомом? Сложный вопрос. Я считаю что в общем случае нельзя. Если это текст или XML
документ - то его поля могут модифицироваться независимо. Тоесть поверх РМД у нас
есть еще другая модель внутри поля где мы также что-то модифицируем.
Налицо - отсутствие 1-НФ. А это ставит под вопрос вообще коцепцию. Зачем
мы берем реляционку если там все равно правила проектирования уже нарушены.

По лимитам и перформансу.

В БД Oracle к примеру существуют серъезные ограничения на длину строки.
Не более 4К. Эти ограничения как-бы подталкивают разработчика к обдумывание
типов данных перед тем как создать таблицу. Вообще очень длинные строки плохо
обслуживаются в РМД. Даже элементарный LIKE или сортировка или comparison
по большим строкам могут серъезно подрубить перформанс. И пока вы будете
копаться в оптимизаторе или еще где-то ваш владелец ПО и пользователи будут
терпеть непонятные падения перформанса на "пустом" месте. И здесь любой
DBA вам скажет что первым делом для устранения этой проблемы надо устранить
сами BLOBS. Иначе перформанса не будет со всеми вытекающими. Потеря репутации.
Недовольство заказчика.

Вобщем нужно беречь и ценить buffer-pool и исключать туда попадания блоков
которые просто заполнены картинками или прочими файлами.

Поэтому если вы решили перенести файлы (объекты не имеющие априори ограничений)
в вашу БД - вы должны понимать что наряду с быстрой SQL-машиной и SQL-сетевым
протоколом который оптимизирован на маленькие строчки (атомы в рамках модели)
вы "включите в игру" огромные длинные бинарные объекты которые участвуют в
буферном кешировании (store blob in row), либо не участвуют но при этом
поиск по ним замедлен из-за того что нет физической консолидации прочитанного
блока с нужными вам данными и собственно файла или BLOB. Архитектурно
во многих DBMS BLOB реализован как аттачмент. Он хранится отдельно от таблички.
JDBC-API видит его как InputStream. К сожалению многие ORM средства создают
дополнительную услугу. (Медвежью услугу). Они презентуют BLOB как строковую
переменную. Создаётся иллюзия что всё нормально. Но на самом деле на уровне
Fetch курсора потребуется сборка его частей из разных физических сегментов.
Здесь нужно думать о lazy-операциях или лучше переписать логику вообще.
По этому таблички с BLOB - медленные по определению. Если вам нужен
перформанс - BLOB - не ваш друг. Ищите альтернатив.

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

казинакmaytonВобщем нужно беречь и ценить buffer-pool и исключать туда попадания блоков
которые просто заполнены картинками или прочими файлами.
nocache
Depends on storage in row.

Товарищ верно заметил надо учесть фактор бюрократии. :)