Использовать Blob или нет (mysql + coldfusion) - PullRequest
2 голосов
/ 28 апреля 2011

Я хотел бы знать, является ли сохранение PDF-файлов в таблице базы данных хорошей долгосрочной идеей.Вот описание проблемы:

У меня есть клиент, у которого есть сотни клиентов, которые загружают многочисленные файлы PDF в качестве доказательства.Размер этих pdf-файлов варьируется от довольно маленьких (<100 КБ) до 10 МБ.Эти файлы могут потенциально загружаться несколько раз, поскольку они являются доказательствами для одного проекта (т. Е. Proof1.pdf, proof2.pdf и т. Д.). PDF-файлы для каждого клиента должны оставаться отдельными, а PDF-файлы для каждого проекта должны оставаться отдельными для каждого клиента. </p>

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

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

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

Итак, в целом, это хорошая идея или я должен выяснить,лучший способ справиться с этим в файловой системе?

Ответы [ 2 ]

7 голосов
/ 28 апреля 2011

Я бы порекомендовал хранить легкие ключи, которые указывают на данные в файловой системе, вместо хранения данных реальных файлов в поле BLOB.Одним из возможных способов было бы хэшировать ваши файлы (скажем, с помощью SHA-1) и использовать этот хеш в качестве имени файла на диске - возможно, даже расположив хранилище в дереве каталогов, которое отображает первые n хеш-символы ( т.е. , 80cdef... может храниться в storage/8/0/c/d/80cdef...).

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

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

0 голосов
/ 28 апреля 2011

Я склонен избегать хранения файлов в базах данных.Я работал с установками Blackboard в кампусе, и вы можете загружать файлы в это приложение.В результате база данных выросла до неуправляемого размера - более 1 ТБ.Система резервного копирования Blackboard упаковывала каждый курс в виде zip-файла, и для полного резервного копирования курса все файлы нужно было извлекать и сжимать ... это стало длительным процессом.Нам приходилось регулярно разбивать (и повторно разбивать) резервные копии.

Вот еще один пост с комментариями: Пост Stackoverflow

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