Как правильно хранить image на сервере (в mysql)?

Здравствуйте, подскажите как лучше всего хранить Image на сервер

Backend - node.js sequalize mysql
Frontend - React.js

Задача такова, что есть обьект в таблице mysql, при запросе с Frontend выводим имя обьекта и фото которое ему принадлежит. Как лучше реализовать хранение image?

Знаю вариант такой:
загружаем файл на сервер - > генерируем имя файла - > генерируем путь -> сохраняем путь к img в поле таблицы обьекта
Как считаете имеет ли смысл искать другое решение или этого будет достаточно?

Дополнительно:

зависит от задачи - если нужна максимальная портативность - то в базе, для хранения в базе нужно использовать ячейки типа blob

Хранить в файлах
Можно не генерировать имя файла а использовать идентификатор из базы данных (не обязательно числовой, можно брать hex от его байтового представления), чтобы не заморачиваться с расширением, его можно либо стандартизировать либо не указывать (но тогда либо где то храни его mime type либо каждый раз высчитывать его с помощью утилиты file). Если будет расширение файла, то веб сервера смогут отдавать такие файлы максимально эффективно статикой, напрямую без бакэнда (при унификации типа файла это не требуется).

Так же для удобства обслуживания действительно больших баз (миллионы изображений) можно раскидывать их по подкаталогам, считая имя каталога как некоторые биты от идентификатора, к примеру имя файла 00f1b3f3.png но хранить его в подкаталоге 00f1/b3f3.png в этом случае один каталог не будет содержать файлов больше некоторого лимита (в данном случае 2^16 - 65536, с таким объемом вполне сносно работают почти любые утилиты)

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

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

Ответы:

Хранить тело бинарного файла в базе — идея ниже среднего и оправдана в редчайших случаях.
Самым распространённым способом сейчас можно назвать использование S3-compatible хранилищ: просто загружаем пользовательский файл туда и храним идентификатор/urn файла.

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

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

• вся суть выбора хранить файлы или в блобах базы в том что запись файла будет проходить в той же транзакции

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

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

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

  А что насчёт создания миниатюр для картинки? Их тоже в базу? Или будем конвертировать на лету через ImgProxy? Но и тут придётся сначала дампить файл на диск.

  Файл — это файл, он должен лежать на диске. На физическом, виртуальном, облачном или каком угодно ещё. Для работы с файлами уже придумана файловая система.

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

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

  Контейнеры и абстракции вида баз данных или облачного хранилища или просто архив (мне к примеру нравятся loopback raw файлы с файловой системой внутри) , это решения, отбирающие все/или часть плюсов отдельного файла ценой каких то бонусов. Только когда потерянные плюсы не критичны а бонусы актуальны, только тогда это действие оправдано, но это происходит очень и очень редко.

  p.s. вот пример не в файлах - https://qna.habr.com/q/10694/#answer_46206

Считаю, что достаточно. Только я бы добавил ещё полей в таблицу — width, height, fileSize, может быть description.

• Тогда лучше сразу таблицу стилей 🙂
• HardBot, Как тебе нравится.

лучше всего в БД
в отдельной myisam таблице