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

Question

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

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

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

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

Answer 1

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

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

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

• Вы можете очень просто доставлять документы через веб-службы .NET, поскольку они поступают прямо в DataTables и легко сериализуются, просто помещая DataTables в DataSet и передавая его.

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

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

• Резервные копии могут быть очень большими

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

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

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

Answer 2

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

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

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

Answer 3

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

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

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

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

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

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

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

Answer 4

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

Answer 5

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

Answer 6

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

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

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

Answer 7

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