Хранить картинки в виде файлов или в базе данных для веб-приложения?

Question

Хранить картинки в виде файлов или в базе данных для веб-приложения?

Свифт 3 версии ответа @Alexey Globchastyy:

class func getGenres(completionHandler: @escaping (genres: NSArray) -> ()) {
...
let task = session.dataTask(with:url) {
    data, response, error in
    ...
    resultsArray = results
    completionHandler(genres: resultsArray)
}
...
task.resume()
}

119

image filesystems database asp.net

задан Community 23 May 2017 в 10:31

8 ответов

В моих недавно разработанных проектах я сохранил изображения (и все виды двоичных документов) как столбцы типа image в таблицах базы данных.

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

Используя сегодняшнюю технологию, я предлагаю, чтобы Вы сохранили изображения в столбцах SQL Server 2008 FILESTREAM (по крайней мере это - то, что я собираюсь сделать со своим следующим проектом), так как они комбинируют преимущество того, чтобы хранить данные в базе данных И наличии больших двоичных файлов в отдельных файлах (по крайней мере, согласно рекламе ;))

11

ответ дан devio 23 May 2017 в 10:31

1

@PaulTDavies, который у меня нет ничего конкретного, образованного для рекомендации прямо сейчас, но msdn.microsoft.com/en-us/library/ms954587 , является основательной сводкой того, куда мои представления прибывают из. А именно, посмотрите " Данные по outside" по сравнению с " Данные по inside" обсуждение. – Daniel Pittman 2 December 2011 в 14:09

Пословица всегда была "Файлами в файловой системе, метаданными файла в базе данных"

7

ответ дан Matt Darby 23 May 2017 в 10:31

1

@DanielPittman Одна проблема с этим подходом: Что, если я хочу искать набор, к которому присоединяются, результатов, фильтрующих на полях в обеих таблицах. Например: Найдите все заказы по £ 100, от клиентов, которые живут в Чешире? Используя подход состава, я должен был бы найти все заказы по £ 100 фунтов от сервиса Порядка и все клиенты из Чешира от Обслуживания клиентов, и затем используют составленный сервис найти пересечение. Набор заказов и клиентов был бы намного больше, чем если бы база данных JOIN использовалась, и производительность была бы значительно уменьшена. – Paul T Davies 7 December 2011 в 00:37

мне обычно нравится иметь двоичные файлы в базе данных потому что:

целостность данных: никакой не имеющий ссылки файл, никакой путь в дб без любого файла не связался
непротиворечивость данных: возьмите дамп базы данных, и это - все. нет "O я забыл к targz этот каталог данных".

6

ответ дан chburd 23 May 2017 в 10:31

1

Вы могли бы хотеть проверить дополнительные шаблоны как CQRS martinfowler.com/bliki/CQRS.html – Arnon Rotem-Gal-Oz 19 November 2011 в 04:53

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

3

ответ дан Dillie-O 23 May 2017 в 10:31

1

@user1035411 I don' t думают, что необходимо копировать данные. Я просто думаю, что сервису Порядка нужно разрешить доступ к Клиенту Services' s данные. Другая вещь рассмотреть состоит в том, что можно хотеть потребительскую таблицу для сервиса Порядка, который содержал бы данные о клиентах, который относится только к сервису порядка. Имя клиента использовалось бы партиями сервисов, так, чтобы остался в Клиенте. но кредитный лимит, возможно, мог бы быть кандидатом на сервис порядка? Это препятствовало бы тому, чтобы дизайн Клиентов изменялся слишком часто. – Paul T Davies 3 December 2011 в 00:18

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

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

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

0

ответ дан MotoWilliams 23 May 2017 в 10:31

1

Я хочу соблюдать принцип SOA, что сервисы только говорят через их интерфейсы, таким образом, я никогда не должен обновлять другие сервисы, если Вы изменяетесь внутренне. Я соглашаюсь с Вами, что сервисы, возможно, должны сохранить другой services' данные. Проблемой является производительность и как сделать кэшированные данные актуальными. Выборка больших объемов данных через SOAP/XML производит тяжелую сетевую нагрузку, в то время как репликация обычно является довольно гладкой. Так как репликация повреждает принцип SOA, я думаю, собираюсь попробовать другой путь и, как Вы предполагаете, только храните минимальное количество данных. – Gruber 5 December 2011 в 20:17

Лучше хранить файлы как файлы. Различные databses обрабатывают данные Блоба по-другому, поэтому если необходимо переместить бэкэнд, Вы могли бы попасть в беду.

При обслуживании impages < img src = в файл, который уже существует на сервере, вероятно, будет более быстрым, чем создание временного файла от поля базы данных и указания на < тег img к этому.

я нашел этот ответ от поиска с помощью Google Вашего вопроса и чтения комментариев в http://databases.aspfaq.com/database/should-i-store-images-in-the-database-or-the-filesystem.html

6

ответ дан sparklewhiskers 23 May 2017 в 10:31

1

Я прочитал Вашу статью. Большое чтение. Я предполагаю кэширование другого services' данные, объединенные с событийно-ориентированным механизмом, который Вы описываете, работали бы. Для сервисов, чьи данные doesn' t часто изменяются, я думаю, что мне могло сойти с рук разрешение сервисам обновить их кэши один раз в ночь, которая устранила бы сложность обработки событий. – Gruber 18 November 2011 в 23:09

Хранение изображений в базе данных добавляет DB наверху для обслуживания единственных изображений и мешает разгружаться для чередования устройства хранения данных (S3, Akami), если Вы растете до того уровня. Хранение их в базе данных делает намного легче переместить Ваше приложение в другой сервер, так как это - только DB, который должен переместиться теперь.

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

4

ответ дан Adam Hawes 23 May 2017 в 10:31

1

Спасибо. Кажется, что у людей есть различные взгляды относительно этого. Если я, например, копирую CustomerService ' s таблица данных Customers (по причинам производительности) к OrderService, я заканчиваю с " spaghetti" проблема, если дизайн Customers потребности изменить---я тогда должен обновить OrderService ' s код. И с SOA that' s, от чего я хочу переехать. – Gruber 2 December 2011 в 19:19

Другие вопросы по тегам:

image filesystems database asp.net

Похожие вопросы:

@PaulTDavies, который у меня нет ничего конкретного, образованного для рекомендации прямо сейчас, но msdn.microsoft.com/en-us/library/ms954587 , является основательной сводкой того, куда мои представления прибывают из. А именно, посмотрите " Данные по outside" по сравнению с " Данные по inside" обсуждение. — Daniel Pittman, 2 December 2011 в 14:09
@DanielPittman Одна проблема с этим подходом: Что, если я хочу искать набор, к которому присоединяются, результатов, фильтрующих на полях в обеих таблицах. Например: Найдите все заказы по £ 100, от клиентов, которые живут в Чешире? Используя подход состава, я должен был бы найти все заказы по £ 100 фунтов от сервиса Порядка и все клиенты из Чешира от Обслуживания клиентов, и затем используют составленный сервис найти пересечение. Набор заказов и клиентов был бы намного больше, чем если бы база данных JOIN использовалась, и производительность была бы значительно уменьшена. — Paul T Davies, 7 December 2011 в 00:37
Вы могли бы хотеть проверить дополнительные шаблоны как CQRS martinfowler.com/bliki/CQRS.html — Arnon Rotem-Gal-Oz, 19 November 2011 в 04:53
@user1035411 I don' t думают, что необходимо копировать данные. Я просто думаю, что сервису Порядка нужно разрешить доступ к Клиенту Services' s данные. Другая вещь рассмотреть состоит в том, что можно хотеть потребительскую таблицу для сервиса Порядка, который содержал бы данные о клиентах, который относится только к сервису порядка. Имя клиента использовалось бы партиями сервисов, так, чтобы остался в Клиенте. но кредитный лимит, возможно, мог бы быть кандидатом на сервис порядка? Это препятствовало бы тому, чтобы дизайн Клиентов изменялся слишком часто. — Paul T Davies, 3 December 2011 в 00:18
Я хочу соблюдать принцип SOA, что сервисы только говорят через их интерфейсы, таким образом, я никогда не должен обновлять другие сервисы, если Вы изменяетесь внутренне. Я соглашаюсь с Вами, что сервисы, возможно, должны сохранить другой services' данные. Проблемой является производительность и как сделать кэшированные данные актуальными. Выборка больших объемов данных через SOAP/XML производит тяжелую сетевую нагрузку, в то время как репликация обычно является довольно гладкой. Так как репликация повреждает принцип SOA, я думаю, собираюсь попробовать другой путь и, как Вы предполагаете, только храните минимальное количество данных. — Gruber, 5 December 2011 в 20:17
Я прочитал Вашу статью. Большое чтение. Я предполагаю кэширование другого services' данные, объединенные с событийно-ориентированным механизмом, который Вы описываете, работали бы. Для сервисов, чьи данные doesn' t часто изменяются, я думаю, что мне могло сойти с рук разрешение сервисам обновить их кэши один раз в ночь, которая устранила бы сложность обработки событий. — Gruber, 18 November 2011 в 23:09
Спасибо. Кажется, что у людей есть различные взгляды относительно этого. Если я, например, копирую CustomerService ' s таблица данных Customers (по причинам производительности) к OrderService, я заканчиваю с " spaghetti" проблема, если дизайн Customers потребности изменить---я тогда должен обновить OrderService ' s код. И с SOA that' s, от чего я хочу переехать. — Gruber, 2 December 2011 в 19:19

score 170 · Accepted Answer

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

, Почему? Поскольку...

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

Вы предполагаете, что Обслуживание клиентов может только получить доступ к Данным о клиентах, и сервис Порядка может только получить доступ к данным Порядка? Я не видел упоминания об этом в Thomas Erl' s книги? Вы могли предоставить ссылку? — Paul T Davies, 2 December 2011 в 00:31