Большой текст и изображения в SQL

Хорошо ли хранить большие объемы текста (например, html-страницы) внутри вашей базы данных SQL? Или лучше ли хранить его в виде файлов html в файловой системе?

То же самое касается изображений - полезно ли хранить данные в базе данных или лучше размещать их на диске?

Будут ли хранить большие объемы данных, например, проблемы с производительностью? Каковы преимущества и недостатки каждого метода хранения?

В терминах размера данных в этом случае я просматриваю область "нескольких страниц" HTML и изображений размером менее 500 КБ (вероятно, намного меньше). Достаточно, чтобы создать свою среднюю веб-страницу для публикации статей в блоге/блоге/etc.

Ответ 1

Сохранение двоичных данных (документов, изображений и т.д.) в базе данных имеет некоторые преимущества.

Вы можете зафиксировать обновление самого документа в той же транзакции, что и информация (имя, дата и т.д.), которые вы хотите сохранить о документе. Это означает, что вам не нужно беспокоиться о написании собственной двухфазной фиксации (хотя в ISTR для SQL Server 2008 есть решение для этого).
Вы можете создать резервную копию всей партии (документы и метаданные) сразу, не беспокоясь о необходимости синхронизации базы данных с файловой системой
Вы можете доставлять документы очень просто поверх веб-сервисов .NET, так как они выходят прямо в DataTables и легко сериализуются, просто помещая DataTables в DataSet и передавая его.
Вы можете применить защиту базы данных к объектам, как и к остальным данным, и не беспокоиться о разрешениях сетевого файла.

У него есть и некоторые недостатки:

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

Все, что сказано, это техника, которую я использую широко, и она работает очень хорошо.

Ответ 2

Чем больше вы вставляете, тем больше вы будете перемещаться, чтобы больше накладных расходов вы создавали.

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

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

Ответ 3

Это вопрос размера. Это зависит от того, насколько велики ваши изображения/текст.

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

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

Ответ 4

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

Ответ 5

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

Ответ 6

Сохранить текст в базе данных

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

На практике большинство сайтов, которые мы развернули, не превышает 10 МБ текстового контента (мы используем нашу собственную систему шаблонов). 10 МБ чистого текста - это много контента (верьте или нет)

Сохранение изображений в файловой системе

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

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

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

Ответ 7

Это была одна из моих дилемм, когда я программировал PHP. Хранение изображений, таких как blobs в базе данных, упрощает управление безопасностью и разрешениями, но это дорого. Я всегда хранили некоторые метаданные в базе данных и двоичное содержимое файловой системы. Доступ к изображениям не был прямым (<img src="image/path" />), но был предоставлен скриптами PHP, которые проверяли аутентификацию и авторизацию пользователей через сеансы перед показом изображения (<img src="showimage.php?id=$id" />). Я предлагаю вам сделать это (какое бы приложение вы ни работали).