Управление файлами

Это утопия. В лучшем случае из-под рук таких пользователей будет выходить что-нибудь монструозное. И это при условии, что сам инструмент получится более-менее годным. Правда, сайты бывают очень разные. Что-нибудь простое и "обвязанное" шаблонами можно сделать. Но я, например, выбрал бизнес-модель, когда пользователи самостоятельно управляют только содержимым и подключением крупных модулей, а во всем остальном полагаются на разработчиков и поддержку.

Слишком абстрактный вопрос. Давайте конкретнее.

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

А как без расширения будет определяться Content-Type? Или вы свой файловый сервер написали, который "подтягивает" метаданные из базы данных? 😃 Проще запретить чему-либо выполняться там, где хранятся загружаемые файлы.

Все запросы у меня обрабатываются через роутер - который передаёт управление в зависимости от расширения. Без расширения передаётся движку на генерацию страницы. Какие то файлы могут на прямую отдаваться CSS, JS, картинки например, какие то генерироваться, те же картинки для изменения размера, капча , json по API и тд. Ну и пользовательские тоже, получить оригинальное имя и расширение файла из базы, в хедер кинуть нужные заголовки и отдать сам файл. Вот и всё.

ЗЫ. Пока я ещё не реализовал управление файлами, рассматриваю ещё варианты.

Конкретнее, как вы делаете управление пользовательскими файлами? Что посоветуете, как лучше сделать?

ЗЫ. Может для каждого пользователя делать поддиректорию? По моему не особо хорошая идея..

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

Может. В некоторых системах я использую такой подход. Имя каталога как раз совпадает с идентификатором пользователя.

Все зависит от конкретной системы. Что у вас, я так и не понял.

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

Интересно, какие это ты собираешься использовать БД, что тебе нужно отдельные классы писать?)))
Проблема в том что у тебя нет разделения логики и ты не очень понимаешь вообще что это такое. Советовать почитать "Основы алгоритмов " не стану, бесполезно. Помню, спрашивал я у тебя сто такое СОЛИД, ответа ты не знал тогда и не знаешь сейчас, раз не можешь решить такую задачу. 

Во-первых, связь с БД должна выть вынесена в адаптер, тогда не придется переписывать все под каждый тип. Нормальные люди используют ОРМ, но это не твой путь. А для получения файлов - отдельный класс, реализация которого не зависит от типа бд.

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

И про какие файлы ты говоришь, которые пользователь должен загружать?

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

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

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

Нет это реалии. Вот как раз у меня недавно был пик нагрузки по одному проекту, по данным статистики хостинга 2500rps было в пике.  Мы каждый год ведем подготовку к этому пику и гоняем 100500 тестов, проверяя 100500 гипотез.  Уверяю вас, что ваше решение будет гарантировано ложиться только из-за такого хранения, даже при значительно меньшем rps. js, css - хранить в таком "формате" это бесполезная трата ресурсов. Т.е. хранить так файлы разумно только в тех случаях, когда есть необходимость ограничивать доступ к файлам.

Но, на сайтах с низкой посещаемостью, позволительно.