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

Ответ 1

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

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

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

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

Ответ 2

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

Помещение в базу данных означает:

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

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

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

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

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

Ответ 3

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

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

Ответ 4

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

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

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

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

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

Ответ 5

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

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

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

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

Ответ 6

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

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

Ответ 7

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

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

: -)

Ответ 8

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

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

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

Ответ 9

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

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

Ответ 10

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

Ответ 11

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

• Упрощенная стратегия резервного копирования
• Документы, хранящиеся в базе данных, можно индексировать и искать
• Вам не нужно беспокоиться о перемещаемых файлах/безопасности, помеченных
• Легко переносить на другой сервер в случае сбоя
• Если правительственные мандаты вы должны хранить данные, возвращающиеся на x лет, управление этим использованием базы данных намного проще.

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

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

Ответ 12

Персональная экспертиза: вы администратор базы данных или программист?

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

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

Ответ 13

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