Oracle CLOB против BLOB - PullRequest
       10

Oracle CLOB против BLOB

0 голосов
/ 15 апреля 2019

Я хочу знать, что Oracle CLOB может предложить по типу данных BLOB. Оба имеют пределы хранения данных (4 ГБ - 1) * DB_BLOCK_SIZE.

Текстовая строка, длина которой превышает 4000 байтов, не может поместиться в столбце VARCHAR2.Теперь я могу использовать CLOB и BLOB для хранения этой строки.

Все говорят: CLOB хорош и предназначен для символьных данных , а BLOB - для двоичных данных, таких как изображения, неструктурированные документы.

Но я вижу, что могу хранить символьные данныевнутри BLOB-а также.

Что я хочу знать:

Итак, вопрос в основах, почему CLOB и почему не BLOB всегда?Есть что-нибудь связанное с кодировкой?

Может быть, вопрос должен звучать так: Как CLOB обрабатывает символьные данные иначе, чем BLOB?

1 Ответ

0 голосов
/ 15 апреля 2019

Я хочу знать, как BLOB обрабатывает данные типа символов.

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

Из документации :

Тип данных BLOB хранит неструктурированные большие двоичные объекты. Объекты BLOB можно рассматривать как битовые потоки без семантики набора символов.


Хранит ли clob сопутствующую информацию вместе с ней и использует ли она при извлечении данных?

Не явно, но данные хранятся в наборе символов базы данных, как с VARCHAR2 данными. Из документации снова :

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

Возможно, вы также заметили, что в пакете dbms_lob есть процедуры для преобразования между типами данных CLOB и BLOB. Для обоих из них вы должны указать набор символов для использования. Поэтому, если вы решите хранить данные символов в качестве BLOB, вы должны знать набор символов при преобразовании их в BLOB, но, возможно, что более важно, вы должны знать набор символов, чтобы иметь возможность преобразовать их обратно. Вы можете сделать это, но это не значит, что вы должны. У вас нет возможности проверить данные BLOB, пока вы не попытаетесь преобразовать их в строку.

Как упоминалось в @APC, это похоже на сохранение даты в виде строки - вы теряете преимущества и безопасность типов, используя правильный тип данных, и вместо этого добавляете дополнительную боль, неопределенность и накладные расходы без какой-либо выгоды.

Вопрос не в том, какие преимущества имеют CLOB по сравнению с BLOB для хранения символьных данных; вопрос действительно обратный: какие преимущества имеют BLOB по сравнению с CLOB для хранения символьных данных? И ответ обычно таков:

@ Boneist упоминает рекомендацию хранить JSON в виде больших двоичных объектов , и есть больше об этом здесь .

(Единственные другие причины, о которых я могу подумать, это то, что вам нужно хранить данные из нескольких исходных наборов символов и сохранять их в точности так, как вы их получили. Но тогда вы либо * * * * * * * * * * * * * * сохраняя их, они никогда не будут проверять или манипулировать данными из самой базы данных и будут возвращать их только в какое-то внешнее приложение без изменений, в этом случае вас не волнует набор символов - поэтому вы обрабатываете чисто двоичные данные и не должны вообще не думайте об этом как о символьных данных, так же как и о том, что сохраняемое вами изображение - это PNG или JPG или что-то еще. Или вам нужно будет работать с данными, и поэтому вам придется записывать, какие набор символов, который представляет каждый объект BLOB, поэтому вы можете преобразовать его по мере необходимости.)

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...