Когда файл - это просто файл?
Итак, вы пишете веб-приложение, и у вас есть несколько областей сайта, куда пользователь может загружать файлы. Мой основной рабочий метод для этого - сохранить фактический файл на сервере и иметь таблицу базы данных, которая связывает сохраненное имя файла с записью, к которой оно относится.
У меня такой вопрос: должна ли быть своя таблица для каждого "типа" файла? Кроме того, должны ли файлы храниться в контекстно-зависимых местах на сервере или все вместе?
Некоторые примеры: фотографии профиля пользователя, резюме заявления о приеме на работу, сопутствующие документы на страницах CMS и т. д.
Ответы 4
Из того, что вы сказали, я бы просто сохранил файлы со случайными (UUID или другими) именами в одном месте. Тогда у меня будет таблица «вложений» или что-то, что содержит ссылки на все ваши внешние файлы. Эта таблица также будет содержать метаданные для этого файла, так что тип файла (изображение, резюме и т. д.) И так далее.
Однако могут быть жесткие ограничения на количество файлов в одном каталоге, в зависимости от того, какую FS вы используете.
Могут быть разные причины для хранения разных файлов в разных местах.
Во-первых, следует рассмотреть ограничение на количество файлов в одном каталоге.
Во-вторых, может возникнуть проблема с безопасностью - если некоторые из них должны быть доступны для всеобщего просмотра (например, фотографии профиля), а другие нет (например, резюме), тогда будет легче управлять их размещением в разных каталогах.
В-третьих, простые административные задачи могут быть проще, если файлы разделены, например, при просмотре в проводнике файлов или управлении резервными копиями или изменении приложения для разделения хранилища файлов в нескольких местах.
Также существует проблема конфликтов имен файлов, но если вы переименуете все в соответствии с полем идентификатора базы данных (например), то это не будет проблемой.
Но, в конце концов, это, вероятно, зависит от объемов и ваших предпочтений.
Другая таблица для каждого типа файла становится актуальной только в том случае, если вы храните другие метаданные (и, следовательно, дополнительные столбцы) для каждого типа файла. Если ваши таблицы для каждого типа файла содержат только одни и те же столбцы (например, имя файла, тип файла, дата загрузки и т. д.), Тогда имело бы смысл разместить их все в одной таблице.
В вашем примере есть аргумент для двух таблиц, поскольку у вас есть файлы, которые могут быть связаны с двумя разными вещами.
- Резюме, фотографии связаны с пользователем.
- вложения связаны со страницей CMS.
Если вы поместите их в одну таблицу (и вы хотите разрешить пользователям иметь более одной фотографии или резюме), вам понадобятся две таблицы ссылок для связывания файлов-> пользователей и файлов-> cms_pages. Возможно, это подразумевает связь HABTM, что неверно и допускает несогласованность данных.
Подход с двумя таблицами немного чище и позволяет связывать файлы только с правильным типом объекта с помощью простого отношения ownTo.
Но я не думаю, что есть какой-то «правильный» ответ на этот вопрос, если только вам не нужно хранить разные типы метаданных для разных типов файлов.
Также не забудьте сохранить или иметь возможность вычислить mimetype для каждого файла, чтобы его можно было правильно вернуть обратно в браузер с правильными заголовками HTTP.