Рекомендуемое место для хранения документов - в базе данных или в другом месте?

Единственное ограничение на хранение документов в базе данных — технологическое.

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

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

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

Основываясь на своем опыте, я бы сказал, что храните их в базе данных. Мы перевели две наши системы для этого.

Внесение в базу данных означает:

• Легко получить доступ даже с нескольких серверов
• Резервное копирование выполняется автоматически (вместо того, чтобы делать это отдельно)
• Вам не нужно беспокоиться о пространстве (поскольку люди держат БД от переполнения диска, но могут забыть следить за тем, где хранятся документы)
• Вам не нужно иметь сложную схему каталогов

У нас были документы вне базы данных. Это становится проблемой с большим количеством документов. Обычный каталог в Linux представляет собой один блок, который обычно составляет 4 КБ. У нас был каталог размером 58 МБ, потому что в нем было так много файлов (это был простой каталог, без иерархии). У него было такое-то количество непрямых блоков. Удаление заняло больше часа. Потребовалось несколько минут, чтобы подсчитать количество файлов в каталоге. Это было ужасно. Это на ext3.

С файловой системой вам нужно:

• Отдельный механизм резервного копирования (из резервной копии БД)
• Чтобы все было синхронизировано (поэтому запись не существует в БД без файла)
• Иерархия для хранения (чтобы предотвратить перечисленные выше проблемы, чтобы ни один каталог не заканчивался 10 000 файлов)
• Какой-то способ просмотреть их с других серверов, если вам нужен кластер (так что, вероятно, NFS или что-то в этом роде)

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

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

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

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

В случае с визуализацией документов 200 миллионов файлов TIFF можно считать относительно большой, но не массивной системой. Системы большего масштаба могут иметь более 1 миллиарда объектных файлов. Скажем, при 20 КБ на битональный TIFF у вас может быть 4 ТБ хранилища объектных файлов. Сколько времени займет резервное копирование вашей БД? Сколько времени будут занимать ваши запросы? Какова частота обращения к этим объектам? Если эти объекты имеют высокую частоту доступа, вы хотите, чтобы ваш высокопроизводительный сервер БД тратил все свое время на обслуживание файлов? Если у вас есть миллионы объектов, вам нужно быть чертовски осторожным в том, как вы разрабатываете решение, в котором объекты хранятся в базе данных.

Предположим, что теперь вам нужно преобразовать эти 200 М файлов TIFF в файлы PDF. Будьте готовы поставить ваше решение на колени, поскольку ваш сервер базы данных тратит свое время на обслуживание каждого объектного файла в процессе преобразования, а затем повторно сохраняет результаты.

Например, Sharepoint известен тем, что хранит объекты в базе данных. Sharepoint также известен проблемами масштабируемости.

Мой ответ:
Для небольших систем (‹ 1M файлов) можно рассмотреть возможность хранения файлов в БД. Для больших систем (> 1M файлов) хранение файлов в БД является ошибкой.

Моя самая большая проблема с хранением файлов в самой базе данных связана с управлением размером и сложностью резервных копий и другими операциями обслуживания базы данных.

Одна из стратегий смягчения этой проблемы (по крайней мере, в MS SQL) заключается в создании отдельных разделов базы данных, потенциально хранящихся на разных дисках.

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

Резервное копирование этих разделов можно выполнять по разным графикам или даже восстанавливать по отдельности.

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

Моя простая точка зрения: файловая система должна хранить файлы, а реляционная база данных должна хранить реляционные данные.

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

Поскольку ваше «количество документов резко растет», похоже, это становится масштабным. Вы можете начать искать готовые решения сторонних производителей (например, http://kofax.com/capture/ — у меня большой опыт в этом!) чтобы сделать «грязную работу» за вас. Или, что еще лучше, рассмотрите предложения SaaS, такие как эти ребята http://www.edocumentsolutionsllc.com/

:-)

Храните документы в виде файлов, например .doc, если вы хотите иметь доступ к файлам, редактировать и сохранять их повторно.

Храните ваши документы в виде файлов, таких как .pdf или .tiff, если вам нужны фактические исторические копии, которые можно восстановить и воспроизвести.

Храните всю информацию о ваших файлах (например, даты, авторы, местоположение) в вашей базе данных.

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

Это обеспечивает гораздо большую гибкость в использовании этих документов. Например, хотите использовать многоуровневое хранилище резервных копий и механизмы дедупликации? Попробуйте это в Oracle BLOB.

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

Личный опыт: вы администратор БД или программист?

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

Новые базы данных совершенствуются в этой области.

Рассмотрите возможность хранения ваших документов в Subversion или другой системе контроля версий. У вас будет хорошая резервная копия, возможность просматривать старые версии документов и отличный доступ к сети. См. "Моя жизнь в подрывной деятельности".

Напротив, я бы пошел на хранение в базе данных по нескольким причинам:

1. Более простая стратегия резервного копирования
2. Документы, хранящиеся в базе данных, можно индексировать и искать
3. Вам не нужно беспокоиться о перемещении файлов или нарушении безопасности.
4. Простота переноса на другой сервер в случае сбоя
5. Если правительство требует, чтобы вы хранили данные за x лет, управлять этим с помощью базы данных намного проще.

Базы данных создаются для хранения данных. Файлы — это просто данные.

Несмотря на то, что у хранения файлов в файловой системе есть преимущества, главное из них — производительность базы данных лучше, а размер меньше. SQL Server 2008 позволяет вам использовать лучшее из обоих миров, используя FileStream. Прочитайте этот технический документ для получения дополнительной информации.