В чем преимущества таблицы uploads для проецирования загруженных файлов в базу данных?

Question

[midia21]

На laravel пишу приложение, где пользователи могут прикреплять изображения к определенным сущностям - допустим загрузить себе аватарку. После такой процедуры картинки попадают в локальное файловое хранилище - в папке storage. Далее, чтобы привязать загруженное изображение к юзеру есть 2 варианта:
1. В колонку avatar просто кинуть текстовый путь до картинки, что-то вроде: uploads/cool_avatar.jpg
2. Создать таблицу uploads и в ней хранить пути ко всем файлам, соответственно в колонку avatar кидать айдишник.

Вопрос: в чем преимущества второго подхода? По моему мнению - первый вариант более простой и менее затратный. К примеру пользователи загрузили в сервис 2 миллиона картинок - в базе добавится 2 миллиона лишних строк, без которых можно было бы обойтись. Тем не менее часто вижу, что таблицу типа "uploads" все таки используют. Чувствую, что этот подход дает больше гибкости, но не особенно понимаю, какой реальный профит от этого можно получить.

Comments

[Everything_is_not_so_bad]

А что произойдет, если пользователь Вася загрузит cool_avatar.jpg, а затем файл с таким же именем загрузит Ваня?

[Арамаис Мирзоян]

Román Mirilaczvili, я думаю для каждого файла нужно сгенерировать уникальное название, чтобы такие проблемы не возникли.

Answer 1

[Dmitry Bay]

В простом варианте для аватаров, да, проще использовать строку.
Но усложняем задачу - вам нужен список предыдущих аватаров, и когда загружены(vk.com к примеру). Каким образом будете реализовать? Для каждого пользователя папку создавать и выпендриваться с файлами?
Или проще создать таблицу - avatars?

Берем другую задачу: человек может загрузить любой файл, и иметь в моменте на него ссылку. А на следующий день как он ее получит? Или через полгода?

Список возможностей, которые мы получаем, если будем использовать бд:
1) Получать список файлов пользователя
2) Группировать файлы
3) Удалять файлы по правилам без проблем.
4) Управлять доступом файла.
5) Использовать авто системы проверки файлов на 18+

Answer 2

[Everything_is_not_so_bad]

Аватарка - это другая сущность, которая сбоку от пользователя.

Answer 3

[pLavrenov]

Только с таблицей.
- Для того чтобы удалять неиспользуемые картинки.
- Для того чтобы делать новые размеры картинок если появляются.
Со временем этот мусор копится и бесполезно сьедает место.

Answer 4

[Арамаис Мирзоян]

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

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

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

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