Каков наилучший способ сохранения и получения бинарных файлов с Oracle 10g?

Question

Я собираюсь реализовать функцию в нашем приложении, которая позволяет пользователю «загружать» документ PDF или Microsoft PowerPoint, который приложение затем сделает доступным для других пользователей в программе просмотра (чтобы они не могли «загрузить» в смысле «Сохранить как ...»).

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

Я знаю, что в Oracle есть способ создать объект 'directory', но есть ли способ использовать эту функцию для хранения и извлечения двоичных файлов, сохраненных в другом месте на сервере базы данных?

Или я слишком параноидален в отношении размера базы данных?

(для полноты картины наше приложение .Net WinForms использует драйверы CoreLab / DevArt OraDirect.Net для Oracle 10g)

Answer 1

Пара опций: Вы можете поместить столбец BLOB в его собственное табличное пространство с его собственными характеристиками хранения; Вы можете хранить большие двоичные объекты в их собственной таблице, связанной с другой таблицей столбцом идентификатора. В любом случае, как вы предложили, вы можете определить столбец как BFILE, что означает, что фактический файл хранится извне из базы данных в каталоге. Здесь может возникнуть проблема в том, что BFILE LOB не участвуют в транзакциях и не восстанавливаются вместе с остальной базой данных.

Все это обсуждается в справочнике по Oracle 10gR2 SQL, глава 2, начиная со страницы 23.

Answer 2

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

Answer 3

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

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

Answer 4

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

Answer 5

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

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

СОЗДАТЬ СТОЛ binary_data1 ФАЙЛ ДАННЫХ some_san_location ХРАНЕНИЕ ПО УМОЛЧАНИЮ (...)

Answer 6

Полагаю, это зависит от того, что вы считаете чрезвычайно большим.

Это действительно зависит от варианта использования. Если к документам обращаются только редко, их размещение в базе данных будет вполне приемлемым (с преимуществом получения «бесплатных» резервных копий, например, с базой данных).

Если это файлы, которые будут попадать снова и снова, вам может быть лучше поместить их непосредственно на диск и просто сохранить местоположение, или даже (если это действительно высокая пропускная способность) посмотреть что-то вроде MogileFS

Никто не сможет дать вам ответ «да» или «нет».