JohnCMS | Upload

# ramzes (23.08.2016 / 15:31)
таблица позволила бы хранить файлы даже удаленно, не то что разбросать их по 100500 каталогам

Вот это правильное замечание

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

Вот с этими превьюшками то и вопрос: как их показывать?
Для картинки превьюшки нужна ссылка на реальный файл,
или если выдаем в формате data:image, тогда превьюшку можно генерить в момент выгрузки файла и хранить в бинарном виде в самой базе данных.

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

З.Ы.
Как вариант, превьюшки можно генерить на лету (напряг для сервера) и сбрасывать в кэш.
Но тут уже надо продумывать алгоритм выборки, а он может оказаться сложнее, чем просто хранить превьюху в базе.

# AlkatraZ (23.08.2016 / 15:45)
Совершенно другая проблема может возникнуть с галереями, где надо хранить кучу фоток (тоже ведь файлы), причем выводить их пачками на страницу и показывать для них превьюшки.

Вот с этими превьюшкам

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

# Simba (23.08.2016 / 15:56)
Превьюхи генерятся и складываются в отдельную папку.

Логично.
Но когда у тебя централизованное хранилище (если именно оно обсуждается), то надо решить, его ли заботы превьюхи, или же их должен генерить и хранить уже сам модуль?

# AlkatraZ (23.08.2016 / 15:59)
Логично.
Но когда у тебя централизованное хранилище (если именно оно обсуждается), то надо решить, его ли заботы превьюхи, или же их должен генерить и хранить уже сам модуль?

Обычно это делает какой нить дополнительный класс ресайзер.
Генерит в отдельную папку превьюхи. При необходимости её можно зачистить и потом по мере входов на страницы превьюхи сгенерятся заново.

# AlkatraZ (23.08.2016 / 15:36)
На кой оно тебе?
По большей части будет запрос на 1 файл.
Даже, если их хранится миллион, клиент загружает только один (надеюсь картинки для интерфейса там хранить не будем гг). В большинстве случае

по большей части это будет от 20 до 500 запросов
давай прикинем:
20 аватар 20ти авторов, 20 скриншотов от 20 файлов 20ти авторов = уже 40
или же форум с 20тью авторами 20ти постов в каждом до 5 файлов = 120.
___
вопрос не в хранении, вопрос в получении пути к уже существующего файла. того же аватара.
и нет, мы не знаем ни каких ид файла, мы обращаемся к хранилищу как к фс, т.е. img/user/avatar/123.png например.
откуда мы узнаем какой ид у этого файла? это знает только бд. точнее это и есть ид сам по себе, уникальный ключ, а нам нужен путь.
из таблицы.
собственно это чисто наметка. сейчас у меня без таблицы работает, удаленно я все равно могу хранить файлы, но автоматическое распределение по хранилищам уже не сделать по человечески, а было бы полезно, масшиабируемость совсем не лишне, одних только фоток на одного пользователя контакта в среднем 50шт, а их миллионы.
тут конечно не контакт, но это и лишь один из множества подпунктов

# AlkatraZ (23.08.2016 / 15:59)
Логично.
Но когда у тебя централизованное хранилище (если именно оно обсуждается), то надо решить, его ли заботы превьюхи, или же их должен генерить и хранить уже сам модуль?

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

если отдельно запрашивать из бд каждый файл
то вот такая штука на сотне онлайна нафиг уронит мускул сервер, а это вполне себе актуальный функционал сайта

# ramzes (23.08.2016 / 16:11)
вопрос не в хранении, вопрос в получении пути к уже существующего файла. того же аватара.
и нет, мы не знаем ни каких ид файла, мы обращаемся к хранилищу как к фс, т.е. img/user/avatar/123.png наприм

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

вот про "определенных полей" как то не понял