Хранить PDF-файлы как двоичные объекты в SQL Server, да или нет? - PullRequest
Новая
       4

Хранить PDF-файлы как двоичные объекты в SQL Server, да или нет?

18 голосов
/ 27 февраля 2010

Мне нужно найти проектное решение для следующей задачи:

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

Сейчас я рассматриваю два варианта хранения документов на веб-сервере:

1) Расширить таблицу заказов на столбец varbinary (MAX) и сохранить документ PDF непосредственно в этом двоичном поле.

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

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

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

Вот дополнительная информация:

  • Файлы PDF будут иметь размер около 100 килобайт каждый
  • Около 1500 заказов / PDF-файлов в месяц
  • Windows Server 2008 R2 / IIS 7.5
  • SQL Server 2008 с пакетом обновления 1 (SP1) Express
  • Не совсем уверен насчет аппаратного обеспечения, я полагаю, один QuadCore Proc. и 4 ГБ ОЗУ
  • Приложение написано в ASP.NET Webforms 3.5 SP1

(Мне известно, что через 2 года я достигну предела в 4 ГБ для выпуска SQL Server Express с указанными выше числами. Но мы можем игнорировать это здесь, либо удаляя старые данные из базы данных, либо обновляя до полной лицензии). будет возможный вариант.)

Мой вопрос: каковы "за" и "против" опций и что бы вы порекомендовали? Возможно, у кого-то была похожая задача, и он может сообщить о своем опыте.

Заранее спасибо за ответ!

Связанный:

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

Ответы [ 6 ]

22 голосов
/ 27 февраля 2010

В SQL Server 2008, когда у вас есть документы размером в основном 1 МБ или более, рекомендуется использовать функцию FILESTREAM. Это основано на статье, опубликованной Microsoft Research, под названием Для BLOB или не для BLOB , в которой анализируются плюсы и минусы хранения больших двоичных объектов в базе данных - отличное чтение!

Для документов размером менее 256 КБ их хранение в столбце VARBINARY(MAX) представляется наиболее подходящим.

Все, что между ними, на самом деле немного путаница.

Вы говорите, что у вас будут PDF-документы, в основном около 100 КБ или около того -> они будут очень хорошо храниться в таблице SQL Server, без проблем. Одна вещь, которую вы могли бы рассмотреть, это наличие отдельной таблицы для документов, которая связана с основной таблицей фактов. Таким образом, таблица фактов будет быстрее в использовании, а документы не будут мешать другим вашим данным.

2 голосов
/ 27 февраля 2010
1 голос
/ 27 февраля 2010

Я бы рекомендовал ПРОТИВ хранения файлов в SQL. Вы добавляете дополнительные издержки при получении файлов. IIS действительно эффективен при обслуживании файлов, но с SQL это средство хранения, которое вы ввели теперь как узкое место, поскольку теперь вам нужно переключиться с веб-сервера на SQL Server и обратно, чтобы получить файл.

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

1 голос
/ 27 февраля 2010

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

0 голосов
/ 12 февраля 2013

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

Пример: 

[SharePoint Base Path][Project Numbe][Project Document Name]
[http://mysharepoint.mycompany.com/213990/213990_PC.pdf]
0 голосов
/ 27 февраля 2010

Я скептически отношусь к хранению больших двоичных объектов в SQL, предполагая, что размер страницы sql равен 4 КБ (не по вкусу). При передаче файла пользователю он должен собрать фрагмент всего файла в nK-блоках уверен, так ли это на самом деле.

...