Базы данных не очень эффективны с BLOB-ами, большими объемами данных, вопрос даже не в скорости работы с ними, а в том что инструменты резервного копирования к примеру будут работать значительно медленее, чем если копировать файлы того же объема но размещенные на диске.
Поэтому вместо хранения файлов, в базе данных размещают способ получения имени файла на диске, иногда это буквально поле с именем файла (например если имя файла такая же полезная информация) а чаще всего это буквально идентификатор с базы данных (число или его hex/base64 представление), иногда это хеш от содержимого (например чтобы эффективно хранить одинаковые файлы) иногда комбинация хеша и имени...
Тебе нужно будет продумать дополнительную прослойку по указанию места на диске для всего каталога (а их может быть несколько) либо помещая идентификатор каталога либо размещая полный путь к файлу (не рекомендую), либо формируя имя из идентификатора (части его бит) либо и то и другое. Рекомендую по возможности сохранять расширение имени файла для быстрой идентификации его типа для веб сервера (который очень эффективно отдает статику из файлов)
Причина - большое (десятки тысяч) количество файлов в одном каталоге не совсем удобно в том плане, что многие утилиты резервного копирования (да и просто работа с файлами, получение списка или удаление с помощью bash rm, он до сих пор глючный и тормозит), поэтому вместо хранения файла 031432532341234123.jpeg делать подкаталоги 0314/3253/2341/234123.jpeg заранее расчитав количество уровней от прогнозируемого количества файлов.
Простой
Простой
