Как лучше хранить изображений? Одна папка или много?

Question

[NikSIk31]

Приветствую! У меня есть БД с ЗАДАНИЯМИ, у каждого задания есть от 0 до 10 фотографий. Как лучше хранить фотографии к заданиям? Сделать поле images в БД (там где и вся инфа о задании) и в этом поле через разделитель хранить названия всех фото жля контретного задания, а все фото в одной папке. Или сделать для каждого задания свою папку и назвать ее по ID задания? Как лучше для производительности? Подскажите пожалуйста

Answer 1

[FanatPHP]

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

Comments

[NikSIk31]

я просто думал сделать в БД таблицу для заданий где вся инфа и заодно пути к картинкам через разделитель. Почему так плохо делать?

[FanatPHP]

погугли свой вопрос, там все разжевано

[alex-1917]

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

[NikSIk31]

alex-1917, а вы какие сайты имеете ввиду?

[alex-1917]

NikSIk31,

бд с заданиями

. сайт по решению домашек для школьнегов, очевидно же

Answer 2

[Gomonov]

Если Вы уверены, что один файл не будет относится более чем к одному заданию - то да, как в ответе выше - один ко многим. Иначе много ко многим. Так же позволю дать рекомендации. Хранить лучше не оригинальное название, а хеш от файла, таким образом сразу решается проблема одинаковых имён файлов. Это поле можно сделать уникальным. Если оригинальное имя необходимо - храните его отдельным полем. По поводу папок. Если это веб-приложение, посещаемость большая и файлов овермного - стоит раскидывать по папкам. Например у вас хеш имеет вид ab1c3fd...... , то можно создать папку с именем из двух первых символов хеша. В данном случае ab - и кинуть файлик туда. Если файлов прям оооооооооочень много, можно делать вторую папку по второй паре символов из хеша. Конечный путь ab/1c/ab1c3fd......

Comments

[NikSIk31]

Я просто слышал, что больше 1000 файлов не очень круто в одной папке хранить, или папки это как бы не изображения и норм? Просто вроде бы при таком раскладе если 26 букв и 10 цифр может быть в одной ячейке (я про "a" в названии папки "ab"), так вот у папки две ячейки (две буквы) и в одной ячейке 36 помещается, т.е. это 32^2 вариантов папок. Это уже за тысячу заходит. Не будет ли это проблемой?

[NikSIk31]

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

[Gomonov]

NikSIk31, немного неправильно считаете. В хеше каждый символ может принимать значения: abcdef0123456789 - всего 16 вариантов. Получается 16^2 - 256. Это количество вложенных директорий. Например есть корневая upload. В ней максимум 256 вложеных. В каждой из них тоже по 256 максимум. И вот в последних уже файлы. При нормальном распределении названий хешей (а оно такое будет), чтобы в директории последнего уровня у вас было более 1000 файлов, всего файлов должно быть 256 * 256 * 1000 = 65536000 файлов

[NikSIk31]

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

[Gomonov]

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

[NikSIk31]

Gomonov, та я уже написал и она не сложная, тут просто вопрос в количестве

[Gomonov]

NikSIk31, если прям хочется заюзать её, используйте например только цифры и названия из трёх символов. Тогда кол-во директорий 10^3 = 1000

Answer 3

[Игорь Воротнёв]

Это называется "отношение 1 к многим", оно же one to many, оно же 1:n. На уровне базы данных выглядит так:

Таблица tasks:
- id
- ...

Таблица photos:
- id
- task_id (foreign key)
- ...

Все фотографии для конкретного задания получаются запросом:
SELECT * FROM photos WHERE task_id=X

В каких папках их хранить на самом диске - вопрос отдельный и по большому счету несущественный.

Comments

[NikSIk31]

Мне казалось логичнее просто выбрать всю инфу одним запросом с таблицы со всеми заданиями и все, а так получается два запроса надо делать. Так разве рациональнее?

[Игорь Воротнёв]

NikSIk31, Да, так рациональнее. Это называется нормализация, и реляционные базы данных как раз вот об этом - мухи отдельно, котлеты отдельно, а между ними связь.

[Игорь Воротнёв]

NikSIk31, А если вас беспокоит "лишний" (на самом деле нет) запрос, то в SQL есть такая штука как JOIN, которая позволит получить все одним запросом. К примеру, по таблицам выше грубо можно запросить так:

SELECT * FROM tasks 
JOIN photos
ON tasks.id=photos.task_id
WHERE task_id=1;

и получить:

id title       id  task_id     path
1  First task   1  1           photos/1.jpg
1  First task   2  1           photos/2.jpg

[NikSIk31]

Игорь Воротнёв, о крутяк, спасибо))

[Евгений Ромашкан]

NikSIk31, Игорь Воротнёв, Нормализация не всегда хорошо, а денормализация не всегда плохо. Я не вижу никаких проблем, например, в данном случае хранить все пути в одном поле, только не через разделитель а в jsonb если на то пошло. Если это видится удобнее.

[Игорь Воротнёв]

Евгений Ромашкан, разумеется баланс должен быть. В данном конкретном случае у нас недостаточно информации, чтобы принимать решение за автора. Впрочем, по поводу json я бы наверное возразил - это дополнительные знания, которые ТСу надо получать. Не стоит усложнять, имхо. Тем более а вдруг придется кроме картинок добавить еще какой-нибудь док, а потом к ним метаданные хранить? Вот тут затея с json уже и боком начинает вылазить. Адекватная же нормализация практически гарантированно избавляет от данных проблем в дальнейшем. Когда говорят "нормализация не всегда хорошо", обычно имеется в виду "по книжке" - минимум 3я нормальная форма, а лучше 4я. Здесь мы настолько не упарываемся.