Дизайн базы данных с большими двоичными объектами - хранить в отдельных таблицах?

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

  • Table One будет хранить файлы *.doc почти для каждой записи.
  • Таблица 2 будет хранить *.xml необязательно.
  • В таблице 3 будут храниться изображения (частота неизвестна).

Является ли это хорошим подходом к поддержанию отдельной таблицы для хранения различных данных больших двоичных объектов, указывающих на соответствующие PK таблицы? (Да, FK не будет, я предполагаю, что программа их поддержит). Это будет что-то вроде ниже,

BLOB|PK_ID|TABLE_NAME

В качестве альтернативы, стоит ли хранить столбцы больших двоичных объектов в отдельных таблицах?

Что касается времени выполнения моего приложения,

Таблицу 2 будут читать очень часто. Хотя столбец больших двоичных объектов не потребуется.
Записи таблицы 2 будут часто удаляться.

Доступ к другим данным больших двоичных объектов в соответствующих таблицах будет осуществляться нечасто. Все содержимое большого двоичного объекта будет считываться по мере необходимости.

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


blob oracle database-design
person user331311    schedule 22.05.2010    source источник

Ответы (1)


arrow_upward
5
arrow_downward

Если между данной записью и большим объектом существует отношение «один к одному», лучше всего объявить столбец большого объекта в записи. Oracle позволяет нам объявить отдельное табличное пространство для LOB, так что это не сильно влияет на хранилище.

create table t23
  ( id number not null
    , col1 number not null
    , col2 date not null
    , col3 varchar2(255)
    , a_doc clob  
    , x_doc xmltype
    , constraint t23_pk primary key (id)
  )
tablespace app_date 
lob (a_doc) store as basicfile a_lob (tablespace lob_data)
lob (x_doc) store as securefile x_lob (tablesapce xml_data)
/

(SECUREFILE — это функция Enterprise Edition, представленная в версии 11g. >Подробнее).

Главное в этом подходе заключается в том, что вам придется явно указать столбцы, которые вы хотите выбрать, если вы не хотите включать столбцы больших объектов. Это не должно быть проблемой, так как это лучшая практика: select * from .... — это ошибка, ожидающая своего появления.

«Таблица три должна будет хранить изображения»

Если у вас отношение «один ко многим», вам потребуется отдельная таблица для изображений.

Есть много тонкостей, когда дело доходит до хранения больших объектов и настройки затронутых запросов. Я рекомендую вам прочитать данный документ Oracle с веб-сайта OTN.

person APC    schedule 22.05.2010
comment
Неосознанно я пытался сделать то же самое, добавив новый столбец в отношения 1-1 и новую таблицу для 1-N. Я не уверен насчет ЛОБ. Я обсужу здесь с экспертами по оракулу и вернусь... Спасибо за ваше предложение. - person user331311; 24.05.2010