Лучший способ хранить двоичные файлы или файлы изображений

Лучшего пути нет.

Что? Вам нужна дополнительная информация?

Я знаю три способа ... Первый - как байтовые массивы в базе данных. Во-вторых, в виде файла с путем, хранящимся в базе данных. Три, как гибрид (только если DB позволяет, например, с типом FileStream ).

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

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

Тогда есть гибридный вариант. Это почти идеально - вы можете получить свои файлы по запросу, но ваша база данных невелика. Решает ли это все ваши проблемы? Возможно нет. Ваша база данных больше не переносима; вы привязаны к конкретной СУБД. И этот материал еще не созрел, так что вы можете наслаждаться процессом прорезывания зубов. И кто сказал, что это решает все различные проблемы?

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

Плюсы хранения бинарных файлов в БД:

• Некоторое снижение сложности со времен уровень доступа к данным уровня вашей системы только интерфейс к БД, а не БД +. файловая система.
• Вы можете обезопасить свои файлы, используя одинаковые полные разрешения безопасность, которая защищает остальное базу данных.
• Ваши двоичные файлы защищены. против проигрыша вместе с остальным ваши данные путем резервного копирования базы данных. Нет отдельной системы резервного копирования файловой системы необходимый.

Cons of Storing binary files in a DB:

• В зависимости от размера/количества файлов, может занять значительное место возможное снижение производительности (в зависимости от того, будет ли твоя двоичная файлы хранятся в таблице, которая часто запрашиваемый контент или нет) и сделать более длительное резервное копирование времена.

Плюсы хранения двоичных файлов в файловой системе:

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

Потребности хранения бинарных файлов в файловой системе:

• Чуть более сложный доступ к данным. слой. Нужна собственная система резервного копирования. Нужно рассмотреть ссылку проблемы целостности (например, удалён указатель в базе данных должен будет приводит к удалению файла таким образом, чтобы не имеют "осиротевших" файлов в файловая система).

В целом я бы использовал файловую систему. Раньше, используя SQL Server 2005, я просто сохранял "указатель" в db-таблицах в двоичный файл. Указатель обычно был GUID.

Хорошая новость, если вы используете SQL Server 2008 (а может быть и другие - я не знаю): есть встроенная поддержка гибридного решения с новым типом данных VARBINARY(MAX) FILESTREAM. Они ведут себя логично, как столбцы VARBINARY(MAX), но за кулисами SQL Sever 2008 будет хранить данные в файловой системе.

Мне нравится хранить изображения в базе данных . Это облегчает переход от разработки к производству, просто меняя базы данных (без копирования файлов). А база данных может отслеживать такие свойства, как созданные/измененные даты, так же как и файловая система.

Лично я никогда не храню изображения в базе данных в целях производительности. На всех моих сайтах у меня есть папка "/files", куда я могу поместить вложенные папки в зависимости от того, какие изображения я буду хранить. Затем я назову их по условию.

Например, если я буду хранить картинку профиля, я буду хранить ее в "/files/profile/" как profile_2.jpg (если 2 - это идентификатор учетной записи). Я всегда делаю правилом изменение размера картинки на сервере на самый большой размер, а затем на меньший, если они мне понадобятся. Поэтому я сохраняю "profile_2_thumb.jpg" и "profile_2_full.jpg".

Создавая правила для себя, вы можете просто в коде вызвать img src="/files/profile__thumb.jpg"

Вот как я это делаю в любом случае!