Как лучше хранить адрес файлов/картинок в базе данных

Question

[Big_Shark]

Всегда задавался вопрос, кто как хранит ссылки на файлы/картинки в базе данных.

Я тут вижу несколько вариантов:

1. хранить только имя картинки file.doc
2. хранить имя картинки и путь относительно папки с загрузками certificate/file.doc
3. хранить полный путь до файла /srv/web/.../upload/certificate/file.doc
4. хранить всю информацию о файле в отдельной таблице, а в нужной нам таблице хранить ID этой записи
5. менять имя картинки на ID записи в базе

Я использую 1 вариант из за его простоты и удобства использования, а какой вариант используйте вы и почему?

Answer 1

[antoo]

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

Comments

[Big_Shark]

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

[Николай Тузов]

> если количество файлов будет большим, то имена могут совпасть
А что мешает проверить имя файла на уникальность, и в случае совпадения, добавлять в конце уникальный идентификатор. И вообще, чем 2-й вариант решает эту проблему? Файлы все равно часто хранятся в одной общей папке

[bdmalex]

И вообще, чем 2-й вариант решает эту проблему? Файлы все равно часто хранятся в одной общей папке
Когда файлов накопится МНОГО и это будет серьёзно тормозить ваш проект — вы с лёгкостью сможете создать ещё одну папку для файлов. Для этого вам и нужен будет второй вариант.

Answer 2

[Ogra]

4й вариант.
1. В отдельной таблице можно хранить оригинальное имя файла, держа его при этом на сервере с хитрой организацией файлов, вида: /ab/bc/de/abbcde.doc
2. Оригинальное имя файла хранится, а значит, если пользователь 1 закачал file.doc, а второй пользователь закачал file.doc, то и при скачивании обоих файлов получится file.doc, а не file(1).doc
3. В таблице можно хранить md5 файла и не забивать место (или даже процессорное время, если происходит обработка картинок/видео) дубликатами.

Ну в общем, этот слой абстракции — никому не мешает.

Comments

[Николай Тузов]

По моему, слишком мудрёно

[ivsedm]

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

[Ogra]

Размер и дату создания еще можно посмотреть в ФС. Но вот с другой метаинформацией — дата последнего обращения, юзер, загрузивший картинку, флаг «временный файл», права доступа уже так не поступишь.
Ну и самое главное — попросит завтра заказчик, чтобы можно было завтра посмотреть историю загрузки файлов/самые большие файлы/добавить счетчик загрузок/сделать премодерацию аваторок/еще что-нибудь и дополнительный слой спасет кучу времени.

[ivsedm]

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

[Big_Shark]

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

[ivsedm]

Ну а если описание, инструкцию производителя и картинки с разных ракурсов? Или такое точно не понадобится?

[Ogra]

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

Answer 3

[bekbulatov]

Следует иметь в виду, что первый вариант не подойдет, если необходимо хранить много картинок. Поиск в папке будет занимать внушительное время, поэтому лучше разбивать на подпапки и хранить относительный путь в БД

Answer 4

[rPman]

Хранить в базе смещение (можно поделить на размер сектора или больше 4096...) и размер файла, при должном красноглазии можно завернуть оба числа в 64bit long и пользоваться им как идентификатор файла, сами файлы хранить в одном большом контейнере (можно не сильно заморачиваться с файловыми системами и складывать прямо в /dev/sda), как результат — максимально быстрый доступ к файлам (быстрее — только при самостоятельной организации кеширования под задачу) и максимально неудобное обслуживание при частых удалениях/изменениях файлов (запись только в конец контейнера, по окончании места — полная реорганизация хранилища, с выдачей новых id… но это может оказаться приемлемой платой и в некоторых задачах ее даже не придется платить).

p.s. посчитали это шуткой? просто все зависит от задачи и особенностей использования данных.
Вышеописанный способ использовался достаточно давно для не web-проекта, обеспечивал 'максимальную из возможных' производительность при резервном копировании, чтении и добавлении новых файлов, позволял организовать версионность 'из каропки',…

Comments

[Arsen]

Очень интересный метод.

[Oleg Shevelev]

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

Answer 5

[Morro]

Первый вариант более гибкий, так как путь к картинке можно указать отдельной директивой конфиг файле приложения.
Например в джанге используется второй вариант — тоже очень неплох, для каждого поля изображения, в модели, можно установить свой путь к изображению (фактически указать директорию куда будет загружаться файл, относительно общей директории загрузки).
Что же относительно полного пути — не очень удобно, так как привязка к расположения файла жосткая.
На щет 4-го варианта — это как-то странно, зачем создавать еще одну таблицу в которой хранить id записи? Сейчас не вижу смысл.
Я бы скорее использовал первый и второй вариант, а выбор между ними зависел от приложения которое я пишу. Четвертый — при условии что у меня очень много данных в таблице, которые нужны с разной степенью релевантности. Те что более востребованы были в таблице А, а те что менее — в В, и связывались по id.

Answer 6

[Евгений Селезнев]

у меня микс 2+4
есть отдельная табличка photos, где хранятся урлы картинок для разных размеров(генерятся в бэкграунде)
в объектах (юзеры или что-то другое) айдишники на фотки.
название папки в которой будет хранится картинка и имя файла генерятся. названия папок имеют вид u_{user_id}, картинки — урезанный md5 от содержимого. Таким образом почти не забочусь о проверке уникальности имен.

Answer 7

[ivsedm]

Ну тут наверное стоит уточнить, что именно хранится в базе. Если это профиль пользователя и путь к единственной аватарке, то можно и 1 вариант использовать. Но могут возникнуть сложности, если захотите все разделять, например, по пользователям или по типам картинок (аватарки отдельно в папке avatars и т.д.). Можно конечно и в логике все это расписать, но почти наверняка будут сложности с количеством правок, если такая переделка возникнет слишком поздно. Поэтому, имхо, предпочтителен вариант 2.
А если это альбомы пользователей с произвольным количеством картинок (и нужна таблица связей), то мне больше нравится вариант 4.

Answer 8

[Николай Тузов]

На мой взгляд, лучший вариант — первый. Это придает гибкость организации хранения файлов. То есть, сегодня ваша папка с файлами называется — «files», а завтра вы решите её назвать «storage». Если вы при этом храните вместе с именем файла часть пути, вам придется редактировать кучу записей. Куда проще, на мой взгляд, указать путь до каталога с файлами в каком нибудь конфиге, а в базе хранить лишь имена.

Действительно, организация файлов очень упростится: например, вы сможете в любой момент рассортировать их по отдельным каталогам ('storage/music', 'storage/images' и т.п.).

> 5. менять имя картинки на ID записи в базе
Этот вариант не конфликтует с первым. Но, целесообразность такого решения зависит от конкретной ситуации.

Comments

[ivsedm]

Вы противоречите сами себе, если хранить только имена (п.1), то каким образом вы добьетесь, чтобы один файл был в 'storage/music', а второй в 'storage/images'?

[Николай Тузов]

А подумать? Пример конфига:
files:
audio: storage/audio
images: storage/images
...
other: storage/other
Тип файла можно хранить в базе

[Ogra]

Хранить в базе и тип файла и его имя? Вот это уже глупость.

[ivsedm]

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

[Николай Тузов]

Ogra, ну или по расширению смотреть. Просто суть не в этом сейчас.

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

[ivsedm]

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

[Николай Тузов]

Зачем так усложнять? Есть таблица файлов, есть каталог с файлами. Где находится каталог, определяется приложением, имя файла определяется в базе, в таблице файлов. Чем плоха такая модель?

[ivsedm]

Тут все комментарии про это… большинство сходится во мнении что 1 вариант возможен, но очень ограничен, как количеством файлов, так и гибкостью использования. Более оптимальный 2. Почему, — читайте комментарии.

Answer 9

[Сергей Савостин]

Смотря какие файлы и для чего.
Если это аватарка пользователя, то ее вообще можно не хранить — переименовываем в [ID].png и кладем в папку /avatars/ Так можно поступать со всеми файлами, привязанными к Primary Key.
Если при этом нужно сохранить имя файла, то опять же можно переименовать в ID, а в базе хранить имя (не подойдет, если у Вас кеширование).
Можно класть в папку /files/[ID]/file.png
Вобщем решение зависит от конкретной задачи.
Полный путь — это конечно же избыточность и негибкость.

Answer 10

[Сергей Савостин]

Гы, а еще файлы можно хранить прям в базе, в BLOB.

Answer 11

[Trash]

Я делаю так - в поле таблицы вписываю через разделитель md5 имена файлов (в общем уникальные выходят), а сами картинки лежат в папке, к примеру, images/2014/08/17/ (год/месяц/день).
Таким образом я могу вытащить любую картинку из базы, опираясь на поле date моей записи в таблице, парсим её на год, месяц и день - добавляем любое имя файла (исходя от разделителя (может быть "запятая")), и вуаля)
Кхм.. А если, к примеру, нужно брать уменьшенные копии, то просто вписываем после нашего images/2014/08/17/ (из примера) строчку "_s/". Выходит - images/2014/08/17/_s/{имя файла}. Мне кажется это достаточно удобный способ, хоть и для моих задач

Comments

[wertex]

А какие у вас в принципе поля таблицы есть?