Хранение изображений в БД - да или нет?

415

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

Как вы думаете, плюсы / минусы?

James Hall
источник
Ну, вы можете сделать оба с транзакционным дисковым кешем .
Река Лилит

Ответы:

350

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

Есть пара вопросов:

  • хранение в базе данных обычно дороже, чем в файловой системе
  • Вы можете значительно ускорить доступ к файловой системе с помощью стандартных готовых продуктов
    • например, многие веб-серверы используют системный вызов sendfile () операционной системы для асинхронной отправки файла непосредственно из файловой системы в сетевой интерфейс. Изображения, хранящиеся в базе данных, не выигрывают от этой оптимизации.
  • такие вещи, как веб-серверы и т. д., не требуют специального кодирования или обработки для доступа к изображениям в файловой системе
  • базы данных выигрывают там, где важна целостность транзакций между изображением и метаданными.
    • сложнее управлять целостностью между метаданными БД и данными файловой системы
    • трудно (в контексте веб-приложения) гарантировать, что данные были записаны на диск в файловой системе
Марк Харрисон
источник
33
какие готовые продукты доступны для «суперускорения» файловой системы?
Андрей Ринея
22
Хотя я управляю только 3 ТБ файлов, я определенно согласен. Базы данных предназначены для структурированных данных, а не для блобов.
Дероберт
7
@derobert: именно так, если вы никогда не будете использовать элемент данных в запросе, в качестве условия или для соединения, он, вероятно, не принадлежит базе данных. Опять же, если у вас есть хорошая функция базы данных для запроса изображений на подобие ...
Нильс Вейнандер
14
какие готовые продукты доступны для «суперускорения» файловой системы?
ablmf
5
Re: «суперускоряющие» продукты: большинство веб-серверов теперь могут использовать системный вызов sendfile () для асинхронной доставки статических файлов клиенту. Он переносит на операционную систему задачу переноса файла с диска на сетевой интерфейс. ОС может сделать это намного эффективнее, работая в пространстве ядра. Мне кажется, это большая победа для файловой системы и базы данных для хранения / обслуживания изображений.
Алан Доннелли
140

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

  • Вы храните изображения, которые динамически изменяются, например, счета-фактуры, и вы хотели получить счет-фактуру, как это было 1 января 2007 года?
  • Правительство хочет, чтобы вы сохранили 6 лет истории
  • Изображения, хранящиеся в базе данных, не требуют другой стратегии резервного копирования. Изображения хранятся в файловой системе
  • Проще контролировать доступ к изображениям, если они находятся в базе данных. Свободные администраторы могут получить доступ к любой папке на диске. Требуется действительно решительный администратор, чтобы подглядывать в базу данных, чтобы извлечь изображения

С другой стороны, есть проблемы, связанные

  • Требовать дополнительный код для извлечения и потоковой передачи изображений
  • Задержка может быть медленнее, чем прямой доступ к файлам
  • Более тяжелая нагрузка на сервер базы данных
рад
источник
2
Отсутствие отдельной стратегии резервного копирования может иметь большое значение, когда вы пишете приложения, установленные на месте (например, SharePoint). При создании резервной копии SharePoint все находится в БД, что делает его очень простым.
Эрик Шуновер
44
Безопасность по неизвестности - это не стратегия контроля доступа!
Джон Кейдж,
5
Я не думаю, что он защищает безопасность неясностью - он говорит, что размещение изображений в БД добавляет еще один уровень безопасности. (Я думаю ... @ Конрад, не хочу вкладывать слова в рот)
Эй Джей.
Я выбрал хранение изображений в базе данных из-за единственного преимущества резервного копирования (или, вообще говоря, хранения всех данных в одном месте), но проблемы, о которых вы говорите, также верны, поэтому я кеширую изображения в файловой системе. Это лучшее из обоих миров, и я удивлен, что ни один из лучших ответов здесь не упоминает об этом.
Барт ван Хейкелом
Вы случайно не используете библиотеку ImageResizing.Net для обработки кэширования образов дисков SQL->? Это самый продвинутый, масштабируемый и надежный дисковый кеш, который вы можете получить ...
Lilith River
56

Это может показаться чем-то большим, но если вы используете (или планируете использовать) SQL Server 2008, я бы рекомендовал взглянуть на новый тип данных FileStream .

FileStream решает большинство проблем, связанных с хранением файлов в БД:

  1. Капли на самом деле хранятся в виде файлов в папке.
  2. В Blobs можно получить с помощью либо соединения с базой данных или через файловую систему.
  3. Резервные копии интегрированы.
  4. Миграция "просто работает".

Однако «прозрачное шифрование данных» в SQL не шифрует объекты FileStream, поэтому, если это важно, вам лучше просто хранить их как varbinary.

Из статьи MSDN:

Операторы Transact-SQL могут вставлять, обновлять, запрашивать, искать и резервировать данные FILESTREAM. Интерфейсы файловой системы Win32 обеспечивают потоковый доступ к данным.
FILESTREAM использует системный кеш NT для кэширования данных файла. Это помогает уменьшить любой эффект, который данные FILESTREAM могут оказать на производительность компонента Database Engine. Буферный пул SQL Server не используется; поэтому эта память доступна для обработки запросов.

Джон Гитцен
источник
+1 для FileStream. На самом деле он сохраняет большие двоичные объекты в виде файлов на диске, но управляет ими транзакционно.
Джон Гитцен
Кроме того, SQL-сервер обеспечивает доступ к
двоичным объектам
Тем не менее, добавленная задержка между БД и веб-сервером ... И веб-сервер должен будет загрузить его в память, чтобы передать его клиенту, вместо того, чтобы передавать его с диска, если только вы не используете кеширование диска.
Река Лилит
39

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

оборота Грег Хурлман
источник
35

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

Патрик МакЭлхани
источник
Очень мило на самом деле. Теперь ваши пользователи могут легко увеличить ваше имя файла, чтобы получить доступ к другим файлам ...
Marijn Huizendveld
6
@Marijn: Это только если вы выставите изображения миру.
Сеун Осева
Мы сделали нечто очень похожее с нашими отображаемыми документами (наш первичный ключ - это составной ключ из трех элементов), но мы добавили дату и время сканирования документа, чтобы мы могли иметь несколько версий в одном каталоге.
Эндрю Нили
@ Osewa, Как это? Да, для прямого доступа к файлу конечному пользователю потребуется доступ к папке. У вас может быть процесс для обслуживания файла через FTP на основе запроса, и безопасность будет на уровне SQL-сервера.
Эндрю Нили
31

Хитрость в том, чтобы не стать фанатиком.

Здесь следует отметить, что никто в лагере профессиональных файловых систем не перечислил конкретную файловую систему. Означает ли это, что все от FAT16 до ZFS легко превосходит каждую базу данных?

Нет.

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

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

dicroce
источник
6
Я не вижу, чтобы кто-то утверждал, что файловая система работает быстрее, чем БД в 100% случаев (прочитайте ответ Марка Харрисона). Это немного соломенный. Вероятно, бывают ситуации, когда предпочтительнее не пристегивать ремень безопасности, но, вообще говоря , носить ремень безопасности - хорошая идея.
Calvin
30

В местах, где вы ДОЛЖНЫ гарантировать ссылочную целостность и соответствие ACID, требуется хранение изображений в базе данных.

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

оборота млюбке
источник
7
На самом деле, нет, вы можете. Поскольку файлы изображений никогда не удаляются, не изменяются и не перезаписываются после создания, все файлы изображений синхронизируются перед попыткой фиксации транзакций, при этом отсутствует повреждение файловой системы, вы можете быть уверены, что файлы изображений и метаданные синхронизированы. Я полагаю, что для некоторых приложений это слишком много.
Сеун Осева
Я бы пошел еще дальше и сказал бы, что с файловой системой Journaling и некоторой дополнительной программной логикой можно достичь соответствия ACID. Шаги будут записывать запись в БД, записывать файл. Если файл фиксируется, передайте транзакцию db.
Эндрю Нили
28

Как уже говорили другие, SQL 2008 поставляется с типом Filestream, который позволяет вам сохранять имя файла или идентификатор в виде указателя в БД и автоматически сохраняет изображение в вашей файловой системе, что является отличным сценарием.

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

Таким образом, вы также экономите место в вашей файловой системе, так как вы собираетесь сэкономить только точное количество места или даже сжатое пространство в файловой системе.

Кроме того, вы можете решить сохранить с некоторой структурой или элементами, которые позволяют вам просматривать необработанные изображения в вашей файловой системе без каких-либо ударов по БД, или переносить файлы в массе на другую систему, жесткий диск, S3 или другой сценарий - обновляя местоположение в ваша программа, но сохраняйте структуру, опять же, без особых усилий, пытаясь извлечь образы из вашей БД при попытке увеличить объем памяти.

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

тигель
источник
27

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

Обслуживание изображений из базы данных легко, просто реализуйте обработчик http, который обслуживает массив байтов, возвращаемый сервером БД, в виде двоичного потока.

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

Вот интересный документ по этой теме.

BLOB или не BLOB: хранение больших объектов в базе данных или файловой системе

Ответ: «Это зависит». Конечно, это будет зависеть от сервера базы данных и его подхода к хранилищу больших двоичных объектов. Это также зависит от типа данных, которые хранятся в BLOB-объектах, а также от способа доступа к ним.

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

Вот еще один момент, который нужно иметь в виду. Одной из причин, поддерживающих использование базы данных для хранения больших двоичных объектов, является соответствие требованиям ACID. Однако подход, использованный тестерами в техническом документе (опция «Bulk Logged» SQL Server), который удваивал пропускную способность SQL Server, фактически изменил «D» в ACID на «d», поскольку данные большого двоичного объекта не регистрировались с помощью начальные записи для транзакции. Поэтому, если полное соответствие ACID является важным требованием для вашей системы, при сравнении операций ввода-вывода файлов и операций ввода-вывода базы данных делите вдвое значения пропускной способности SQL Server для операций записи в базу данных.

user13550
источник
25

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

Когда-то общее решение этого состоит в том, чтобы объединить их в сбалансированное дерево подкаталогов.

Джон
источник
Вы бы так подумали, но проблемы на самом деле незначительные; У меня есть приложение с миллионами файлов в одном каталоге, доступ к которому имеют сотни пользователей, без проблем. Это не умно, но это работает. Самая большая проблема в том, что если вы используете Проводник для просмотра каталога, вы всегда смотрите на фонарик.
SqlACID
1
Лучше использовать файловую систему, которая не имеет проблем с большими каталогами
Seun Osewa
8
У меня было приложение с миллионами файлов в одном каталоге (сервер, на котором запущен RHEL 4) - даже для составления списка содержимого каталога (передачи в файл) потребовались дни, и был создан выходной файл размером 100 МБ. Теперь они находятся в базе данных. У меня есть один файл, который я могу легко переместить или создать резервную копию.
Ричард
1
@Seun Osewa: каждая файловая система имеет ограничения ... и если вы знаете одну, у которой нет проблем с хранением миллионов записей в одном каталоге, пожалуйста, дайте мне знать!
Гийом
1
@Seun Osewa: база данных до 28 ГБ сейчас, с 5,4 млн записей. В итоге мне пришлось разделить таблицу базы данных, чтобы у меня было несколько файлов для резервного копирования размером около 5 ГБ. Теперь я могу перенести отдельные изображения на Amazon S3, поэтому мне нужно только сохранить имя файла в БД (а Amazon может делать резервные копии). )
Ричард
22

Что-то, что никто не упомянул, это то, что БД гарантирует атомарные действия, целостность транзакций и имеет дело с параллелизмом. Даже ссылочная целостность выходит за рамки с файловой системой - так как вы знаете, что ваши имена файлов действительно все еще правильны?

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

Мы используем большие двоичные объекты, потому что ими проще управлять (резервное копирование, репликация, передача). Они хорошо работают для нас.

Draemon
источник
Какова вероятность наличия двух одновременных обновлений для определенного изображения?
Арафангион,
1
Вам не нужны одновременные обновления, чтобы иметь проблемы - это может быть чтение и запись. В нашем случае это почти гарантировано.
Draemon
20

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

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

Учитывая, что изображения являются фактическими запрашиваемыми данными, и что ими можно легче управлять (изображения не исчезнут внезапно) в одной интегрированной базе данных, вместо того, чтобы взаимодействовать с какой-либо файловой системой (если к файловой системе осуществляется независимый доступ, изображения МОГУТ внезапно «исчезнуть»), я бы пошел на хранение их непосредственно как BLOB или что-то подобное.

Мудрый парень
источник
17

В компании, где я работал, мы хранили 155 миллионов изображений в базе данных Oracle 8i (тогда 9i). 7,5 ТБ стоит.

graham.reeds
источник
5
Абсолютно. Очевидно, база данных теперь намного больше. Наличие данных в базе данных означает, что репликация базы данных на разных сайтах также намного проще.
graham.reeds
Я видел демонстрацию Oracle, где можно было смонтировать файловую систему в базу данных или что-то в этом роде. Знаете ли вы, если это то, что вы сделали? (Извините, я не разбираюсь в Oracle, поэтому, может быть, я говорю мусор.)
Стю Томпсон,
Я так не думаю - это было хранение изображений в базе данных в качестве базы данных. База данных была агрессивно настроена - я помню многократные обсуждения относительно размера изображений, изменяющихся, поскольку поля были добавлены и удалены. Все было выровнено по границе.
graham.reeds
14

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

Как и большинство других вещей, это зависит от ожидаемого размера и бюджета.

Майкл Стум
источник
13

Мы внедрили систему обработки документов, которая хранит все свои изображения в полях BLOB-объектов SQL2005. На данный момент существует несколько сотен ГБ, и мы наблюдаем отличное время отклика и практически полное снижение производительности. Кроме того, для соответствия нормативным требованиям у нас есть промежуточный уровень, который архивирует вновь размещенные документы в оптическую систему музыкального автомата, которая представляет их в виде стандартной файловой системы NTFS.

Мы были очень довольны результатами, особенно в отношении:

  1. Простота репликации и резервного копирования
  2. Возможность легко внедрить систему управления версиями документов
dan90266
источник
11

Если это веб-приложение, то могут быть преимущества хранения изображений в сторонней сети хранения данных, такой как Amazon S3 или платформа Nirvanix.

Дэвид
источник
11

Предположение: приложение доступно через Интернет

Я удивлен, что никто на самом деле не упомянул об этом ... делегировать это другим специалистам -> использовать стороннего провайдера изображений / файлового хостинга .

Храните свои файлы на платном онлайн-сервисе, например

Другие потоки StackOverflow говорят об этом здесь .

В этой теме объясняется, почему вы должны использовать сторонний хостинг-провайдер.

Это того стоит. Они хранят это эффективно. Нет загрузки с ваших серверов на запросы клиентов и т. Д.

Чисто.Кроме
источник
10

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

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

a7drew
источник
+1 Это также позволяет вам сохранять исходное изображение, предоставляя кэшированную / оптимизированную версию, а также возможность изменения размера / сжатия позже
Deebster
7

Я не уверен, насколько это пример из "реального мира", но в настоящее время у меня есть приложение, в котором хранятся данные для торговой карточной игры, включая изображения для карт. Предполагается, что количество записей для базы данных на сегодняшний день составляет всего 2851 записей, но, учитывая тот факт, что некоторые карты выпущены несколько раз и имеют альтернативное оформление, на самом деле было более эффективно сканировать «первичный квадрат» рисунка, а затем динамически генерировать границы и прочие эффекты для карты по запросу.

Первоначальный создатель этой библиотеки изображений создал класс доступа к данным, который отображает изображение на основе запроса, и делает это довольно быстро для просмотра и отдельной карты.

Это также облегчает развертывание / обновление при выпуске новых карт, вместо того, чтобы архивировать всю папку с изображениями и отправлять их по конвейеру, а также убедиться, что создана правильная структура папок, я просто обновляю базу данных, и пользователь снова загружает ее. В настоящее время его размер составляет до 56 МБ, что не очень хорошо, но я работаю над функцией постепенного обновления для будущих выпусков. Кроме того, существует версия приложения «без изображений», которая позволяет пользователям, подключенным к сети, получить приложение без задержки загрузки.

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

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

Dillie-О
источник
При работе с репликацией хранение изображений в базе данных намного лучше IMO.
Звуковой сигнал
7

SQL Server 2008 предлагает решение, которое имеет лучшее из обоих миров: тип данных файлового потока .

Управляйте им как обычной таблицей и обладайте производительностью файловой системы.

Андрей Ринея
источник
7

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

ИМО, Плюсы использования базы данных для хранения изображений,

A. Вам не нужна структура FS для хранения ваших изображений
B. Индексы базы данных работают лучше, чем деревья FS, когда нужно хранить большее количество элементов
C. Грамотно настроенная база данных отлично справляется с кэшированием результатов запроса
D. Резервные копии просты. Это также хорошо работает, если у вас настроена репликация и контент доставляется с сервера рядом с пользователем. В таких случаях явная синхронизация не требуется.

Если ваши изображения будут маленькими (скажем, <64 КБ), и механизм хранения вашей базы данных поддерживает встроенные (в записи) большие двоичные объекты, это еще больше повышает производительность, поскольку не требуется косвенного обращения (достигается локальность ссылок).

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

nikhilbelsare
источник
7

Недавно я создал приложение PHP / MySQL, которое хранит файлы PDF / Word в таблице MySQL (до 40 МБ на файл).

Плюсы:

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

Минусы:

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

Я бы назвал мою реализацию успешной, она заботится о требованиях резервного копирования и упрощает макет проекта. Производительность хорошо для 20-30 человек, которые используют приложение.

слишком много PHP
источник
6

По своему опыту я должен был управлять обеими ситуациями: изображения, хранящиеся в базе данных, и изображения в файловой системе с путем, сохраненным в БД.

Первое решение, изображения в базе данных, несколько «чище», поскольку вашему слою доступа к данным придется иметь дело только с объектами базы данных; но это хорошо только тогда, когда вам приходится иметь дело с небольшими цифрами.

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

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

Еще одна причина, по которой стоит обратиться к файловой системе, - это когда вам приходится делиться данными изображений (или звуками, видео и т. Д.) С доступом третьих лиц: в настоящее время я занимаюсь разработкой веб-приложения, в котором используются изображения, к которым необходимо получить доступ "извне". «Моя веб-ферма такова, что доступ к базе данных для получения двоичных данных просто невозможен. Так что иногда есть и конструктивные соображения, которые приведут вас к выбору.

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

ila
источник
4

Я когда-то работал над приложением обработки изображений. Мы сохранили загруженные изображения в каталоге, который был что-то вроде / images / [сегодняшняя дата] / [id номер]. Но мы также извлекли метаданные (exif-данные) из изображений и сохранили их в базе данных вместе с отметкой времени и тому подобным.

Томас Оуэнс
источник
4

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

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

Кристоффер Хаммарстрём
источник
3

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

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

Похоже, что это было бы лучше решить с помощью промежуточного скрипта, извлекающего данные из недоступного в сети хранилища файлов. Таким образом, хранение БД НЕ ДЕЙСТВИТЕЛЬНО необходимо.

Джефф
источник
3

Уличное слово гласит, что если вы не являетесь поставщиком баз данных, пытаясь доказать, что ваша база данных может это сделать (например, скажем, Microsoft хвастается тем, что Terraserver хранит баджиллионные изображения в SQL Server), это не очень хорошая идея. Когда альтернатива - хранение изображений на файловых серверах и пути в базе данных намного проще, зачем беспокоиться? Поля BLOB-объектов похожи на внедорожные возможности внедорожников - большинство людей ими не пользуются, те, кто обычно попадают в беду, а есть и такие, которые делают это, но только для удовольствия.

deadprogrammer
источник
3

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

+ VES:

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

-ves:

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

Оба метода распространены и практикуются. Посмотрите на преимущества и недостатки. В любом случае, вам придется подумать о том, как преодолеть недостатки. Хранение в базе данных обычно означает настройку параметров базы данных и реализацию некоторого вида кэширования. Использование файловой системы требует, чтобы вы нашли какой-то способ синхронизации файловой системы + базы данных.

Салман А
источник