2010-11-07 6 views
0

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

Я делаю форму для сайта, и эта форма содержит раздел загрузки изображений. В этом разделе изображения загружаются до отправки формы (через iframe). Поскольку форма еще не отправлена, у меня нет записи DB, чтобы связать изображения так, чтобы я делал это при каждой загрузке. Я вставляю маркер изображения в форму. Когда форма отправляется, я петлю с помощью токенов и свяжу их с вновь созданной записью БД.

Может быть важен:

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

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

Что вы, ребята, думаете?

EDIT: Я забыл упомянуть, но создаю миниатюру для изображения, чтобы согласиться с оригиналом. Должен ли я просто добавить «_thumb» к имени файла и поместить его туда, где оригинал? Должна ли версия миниатюр иметь собственную запись базы данных? Заранее спасибо.

+0

Что говорит против именования загруженного файла после создания записи БД, например. используя mySQL 'LAST_INSERT_ID()'? –

+0

Я подумываю сделать что-то, что я прочитал на этом сайте: md5 (microtime()). $ User_id; затем беру первые 3 символа, чтобы создать 3 каталога. Итак, «5b73e1993b» приведет к «/5/b/7/5b73e1993b.jpeg». Как вы думаете? – RS7

ответ

0

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

Edit:

Вы можете сохранять метаданные изображения, включая все изображения и эскизы (как BLOB) в базе данных. Вы также можете хранить изображения в файловой системе и сохранять только метаданные в базе данных. Это действительно зависит от вас, если вы хотите сохранить разные версии каждого изображения (wiki-style). Это позволяет пользователю откатиться к предыдущей версии. Вы также можете просто перезаписать любую предыдущую версию изображения, которая может сэкономить много места на диске. Все, что имеет суффикс _thumb, может автоматически ассоциироваться с родительским изображением. Я не вижу в этом проблемы.

+0

Мне нужно было проверить, существует ли файл, переместить его и записать, да? (после подачи формы). Должны ли разные версии изображения иметь собственную запись базы данных или я должен просто добавить «_thumb» и такую, но только одну запись для оригинала? – RS7

+0

См. Мой отредактированный ответ. – stillstanding

0

Я делаю это.

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

<token>_<timestamp>.jpg 

раз изображение, его закачано я отвечаю с именем изображения и сохранить его на скрытом значении.

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

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

0

Мне нужно было очищать неиспользуемые файлы так часто.

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

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

Смежные вопросы