Хранение изображений в базе данных по сравнению с файловой системой

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

У меня есть веб-сайт, который позволяет администраторам загружать фотографии сотрудников. Пока эти снимки хранятся в BLOB в моей базе данных MySQL. Кроме того, у меня есть приложение для Windows, которое работает рядом с веб-сайтом. Это приложение позволяет сотрудникам вставлять и отображать свои фотографии, когда они это сделали. Изображение извлекается через запрос mysql в приложении (из нелокального удаленного места), который преобразует содержимое изображения в считываемое изображение, которое выводится в окне изображения, подтверждающее личность сотрудника.

В моих глазах гораздо проще иметь изображения, хранящиеся в базе данных, и получать их через простой запрос. Я нашел это намного проще, чем хранить пути изображения в базе данных и иметь дело с приложением, загружающим изображения. Мне также не нужно иметь дело с коллизиями, организацией папок, безопасностью и путями, которые переписываются по причинам x, y и т.д. И т.д.

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

Любая помощь по этому поводу будет очень признательна. Если этот вопрос не будет здесь, я буду рад его перенести.

ОТВЕТЫ

Ответ 1

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

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

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

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

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

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

Ответ 2

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

1) Сервер будет иметь информацию о временной отметке, связанную с файлами, которые база данных не отслеживает. если вам когда-нибудь понадобится это для судебной экспертизы, решение БД, вероятно, будет ограничено в этом отношении. Не стесняйтесь сохранять информацию об изображениях, загруженных в отношении информации о IP-адресах, метке времени и т.д. В DB, хотя тоже.

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

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

Чтобы избежать коллизий имен, если бы я был в ящике Linux, я бы использовал что-то вроде отметки времени Unix в качестве префикса для имени файла при его сохранении или просто использовал (+, может быть, короткую случайную #), как изображение ID вообще. Поэтому вместо "jane-image.jpg" это будет "1407369600_img3547.jpg". Затем просто поставьте ссылку на то, что в БД и альте, это случайный достаточно ID, где никогда не должно быть столкновения, если время не начнет течь назад. Независимо от того, какой эквивалент timestamp Windows будет использоваться, очевидно.

ПРИМЕЧАНИЕ. То, что вы сейчас делаете, неплохое и похоже на то, что это может сработать лучше всего для вас... но, вообще говоря, я стараюсь не ставить все в руки базы данных, просто потому, что могу, Но вот я:)