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

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

У меня есть база данных 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 SP1 Express
Не совсем уверен в аппаратном обеспечении, я считаю, что один QuadCore Proc. и 4 ГБ оперативной памяти.
Приложение написано в ASP.NET Webforms 3.5 SP1

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

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

Заранее благодарю за ответ!

Связанный:

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

Ответ 1

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

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

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

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

Ответ 2

Это было задано много раз о хранении изображений, но обсуждение этих вопросов по-прежнему применяется:

Ответ 3

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

Ответ 4

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

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

Ответ 5

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

Ответ 6

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

Пример:

[SharePoint Base Path][Project Numbe][Project Document Name]
[http://mysharepoint.mycompany.com/213990/213990_PC.pdf]