Дизайн базы данных с каплями - хранить в отдельных таблицах? - PullRequest
2 голосов
/ 22 мая 2010

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

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

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

BLOB|PK_ID|TABLE_NAME

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

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

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

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

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

1 Ответ

4 голосов
/ 22 мая 2010

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

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 .

...