Каков наилучший способ связать файл с частью данных?

Question

У меня есть приложение, которое создает записи в таблице (ракетостроение, я знаю). Пользователи хотят связать файлы (.doc, .xls, .pdf и т. Д.) С одной записью в таблице.

• Должен ли я хранить содержимое файл (ы) в базе данных? Не было бы это раздувать базу данных?

• Должен ли я хранить файл (ы) в файле сервер, и сохраните путь (и) в базы данных?

Каков наилучший способ сделать это?

Answer 1

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

Хранить файлы в БД

Большинство rbms поддерживают хранение больших двоичных объектов (или данных двоичных файлов, .doc, .xls и т. Д.) В БД. Таким образом, вы не открываете здесь новые возможности.

Плюсы

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

Против

• Резервные копии могут быстро превратиться в ОГРОМНЫЙ кошмар, когда вы храните все эти двоичные данные в своей базе данных. Вы можете уменьшить некоторые головные боли, храня файлы в отдельной БД.
• Без БД или интерфейса с БД нет простого способа получить доступ к содержимому файла, чтобы изменить или обновить его.
• В общем случае его сложнее кодировать и координировать загрузку и хранение данных в БД по сравнению с файловой системой.

Хранить файлы в файловой системе

Этот подход довольно прост, вы сами храните файлы в файловой системе. В вашей базе данных хранится ссылка на местоположение файла (а также все метаданные о файле). Одним из полезных советов здесь является стандартизация схемы именования файлов на диске (не используйте файл, предоставленный пользователем, создайте его самостоятельно и сохраните их в БД).

Плюсы

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

Против

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

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

J

Answer 2

Насколько хорошо вы можете хранить двоичные файлы или BLOB-объекты в базе данных, будет сильно зависеть от используемой вами СУБД.

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

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

У нас была система, которая должна была хранить несколько тысяч файлов в файловой системе, в файловой системе, где нас беспокоило количество файлов в какой-либо одной папке (я думаю, это могла быть FAT32).

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

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

Если бы после этого у все еще возникла коллизия имени файла, мы просто добавили бы "_ n " к имени файла (до расширения), где n был просто увеличивающимся числом, пока мы не получили имя, которого не было (и даже тогда, я думаю, мы сделали атомарное создание файла, просто чтобы быть уверенным).

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

Answer 3

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

Все зависит (в конце концов) от реальных требований пользователя.

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

Раздувание базы данных является проблемой только в том случае, если вы ее не выбрали. Сделайте несколько тестов и посмотрите, какие эффекты это имеет. 100 ГБ файлов на диске, вероятно, так же велики, как и те же файлы в базе данных.

Answer 4

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

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

Если существует слишком много неизвестных, использование файловой системы является более безопасным маршрутом.

Answer 5

Сохранение путей в базе данных. Это предотвращает вздутие базы данных, а также позволяет отдельно создавать резервные копии внешних файлов. Вы также можете переместить их более легко; просто переместите их в новое место, а затем ОБНОВИТЕ базу данных.

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

• Запрос к базе данных для получения содержимого файла в BLOB-объекте
• Запись данных большого двоичного объекта в файл на диске
• Запустите приложение для открытия / редактирования / любого файла, который вы только что создали
• Считать файл обратно с диска в BLOB-объект
• Обновить базу данных новым содержимым

Все это в отличие от:

• Считать путь к файлу из БД
• Запустите приложение для открытия / редактирования / любого файла

Я сам предпочитаю второй набор шагов.

Answer 6

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

Кроме того, ваш веб-сервер может, вероятно, обслуживать файлы более эффективно, чем код вашего приложения (для потоковой передачи файла из БД обратно клиенту).

Answer 7

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

Answer 8

А теперь для полностью автономного предложения - вы можете рассмотреть возможность хранения двоичных файлов как вложений в CouchDB базе данных документов. Это позволит избежать проблем, связанных с конфликтом имен файлов, так как вы будете использовать сгенерированный UID в качестве каждого идентификатора документа (который вы будете хранить в своей РСУБД), а фактическое имя файла вложения сохраняется вместе с документом.

Если вы строите веб-систему, то тот факт, что CouchDB использует REST поверх HTTP, также может быть использован. И есть также средства репликации, которые могут оказаться полезными.

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