MySQL Design для пользовательской фотогалереи

Question

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

Прямо сейчас вот что у меня есть:

photo_gallery

photo_id -    image             - sort_order - user_id
1        -    test.jpg          - 1          - 1
2        -    another_photo.jpg - 2          - 1

А затем в структуре папок я бы создал новую папку примерно так: images / photo-gallery / и сохраняйте изображения там. Теперь я должен создать папку для каждого user_id и сохранить их конкретные изображения в этой папке /

Так что в этом случае: images / photo-gallery / 1 / test.jpg и все фотографии пользователя 1 будут там?

Также для изменения размера я думаю об использовании интеллектуального изменения размера изображения , чтобы я мог просто сохранить исходную фотографию, и если я хочу изменить ее размер до определенного размера, я могу просто вызвать ее скрипт, например: /image.php?width=200&height=200&image=test.jpg.

Должен ли я хэшировать эти имена файлов? Я что-то пропустил? Любые предложения о том, как улучшить это?

Спасибо!

Answer 1

Теперь, я должен создать папку для каждого user_id и сохранить их определенные изображения в этой папке?

Да, было бы неплохо как-то разделить закачки, чтобы у вас не было одного каталога, содержащего десятки тысяч файлов. Вы можете разделить их по идентификатору пользователя, по первым буквам (например, images / t / te / test.jpg) или по хешу (например, images / 0e / 0e4fab12.jpg).

---

Должен ли я хэшировать эти имена файлов?

Это зависит от того, чего вы пытаетесь достичь. Поскольку вы планируете ссылаться на имена файлов в URL, сохранение имени файла с известным набором «безопасных» символов может быть преимуществом:

image.php?image=c/ca/cat%20farting%20On%20a%20lemon.jpg
 -- vs --
image.php?image=0a/0a1b2c3d.jpg

Однако, если вы сделаете это, я бы предложил расширить схему вашей базы данных, включив в нее исходное имя файла:

photo_id | image           | orig_fn           | sort_order | user_id
1        | 0a/0a1b2c3d.jpg | charginLazors.jpg | 1          | 2

Вы можете также рассмотреть возможность хранения дополнительных метаданных об изображении, таких как дата загрузки, подпись и т. Д.

---

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

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

• Один персонаж & mdash; 16 подпапок
• Два символа & ndash; 256 подпапок
• Три символа & mdash; 4096 подпапок

Если вы используете более двух символов, я бы предложил вложить папки еще дальше: 0a/0a12/0a12bd31.jpg -или- 0a/12/0a12bd31.jpg. Это делает навигацию / управление файлами более управляемыми (IMO)

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

Answer 2

Теперь я должен создать папку для каждого user_id

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

Также для изменения размера я подумываю об использовании интеллектуального изменения размера изображения

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

Я что-то пропустил?

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

Есть предложения, как это улучшить?

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