Разумно ли использовать небольшие капли в Oracle?

Question

В Oracle LongRaw и Varchar2 имеют максимальную длину 4 КБ в Oracle, но мне нужно хранить объекты размером 8 КБ и 16 КБ, поэтому мне интересно, что является хорошим решением. Я знаю, что мог бы использовать Blob, но Blob имеет переменную длину и, если я не ошибаюсь, является дополнительным файлом за кулисами, функцией и ценой, которые я не заинтересован в оплате своих объектов. Существуют ли другие решения или типы данных, более подходящие для такого рода потребностей?

Спасибо

Answer 1

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

Answer 2

Вы должны использовать BLOB.

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

Если ваши BLOB-данные действительно малы, вы можете заставить Oracle хранить их в линейке с другими данными в вашей строке (например, varchar2).

Внутренне Oracle делает нечто похожее на то, что предлагал PAX. Куски такие же большие, как блок БД, за вычетом некоторых накладных расходов. Если вы попытаетесь заново изобрести функции Oracle поверх Oracle, это будет только медленнее, чем встроенная функция.

Вам также придется заново реализовать целую кучу функций, которые уже предоставлены в DBMS_LOB (длина, сравнения и т. Д.).

Answer 3

Не храните двоичные данные в столбцах varchar2, если вы не хотите их кодировать (base64 или аналогичные). В противном случае проблемы с набором символов могут повредить ваши данные!

Попробуйте следующее утверждение, чтобы увидеть эффект:

выберите * из (выберите оригинал rownum-1, данные ascii (chr (rownum-1)) из user_tab_columns, где rownum <= 256), где оригинальные <> данные;

Answer 4

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

Это обеспечит расширение, если оно понадобится вам в будущем.

Например:

Primary table: -- normal columns -- chunk_id integer chunk_last_len integer Chunk table: chunk_id integer chunk_sequence integer chunk varchar2(whatever) primary key (chunk_id,chunk_sequence)

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

Answer 5

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