Как хранить неограниченное количество символов в Oracle 11g?

Question

У нас есть таблица в Oracle 11g со столбцом varchar2. Мы используем проприетарный язык программирования, где этот столбец определен как строка. Максимум мы можем хранить 2000 символов (4000 байт) в этом столбце. Теперь требование таково, что в столбце должно храниться более 2000 символов (фактически неограниченное количество символов). Администраторы баз данных не любят типы данных BLOB или LONG по причинам обслуживания.

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

Есть ли лучшее решение этой проблемы?

ОБНОВЛЕНИЕ: проприетарный язык программирования позволяет определять переменные типа string и blob, опция CLOB отсутствует. Я понимаю ответы, но я не могу взять на себя администраторов баз данных. Я понимаю, что отклонение от BLOB или LONG будет кошмаром для разработчиков, но все равно не могу с этим поделать.

ОБНОВЛЕНИЕ 2: Если мне нужно максимум 8000 символов, могу ли я просто добавить еще 3 столбца, чтобы у меня было 4 столбца с 2000 символами в каждом, чтобы получить 8000 символов. Поэтому, когда первый столбец заполнен, значения будут перетекать в следующий столбец и так далее. У этого дизайна будут какие-нибудь плохие побочные эффекты? Пожалуйста, предложите.

Answer 1

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

Также вы можете посмотреть на тип CLOB , поскольку он вполне удовлетворит ваши потребности.

Answer 2

Вы можете следовать тому, как Oracle хранит свои хранимые процедуры в информационной схеме. Определите таблицу с именем текстовые столбцы:

CREATE TABLE MY_TEXT (
IDENTIFIER INT, 
LINE       INT,
TEXT       VARCHAR2 (4000),
PRIMARY KEY (INDENTIFIER, LINE));

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

Да, это не так эффективно, как blob, clob или LONG (я бы избегал полей LONG, если это вообще возможно). Да, это требует большего обслуживания, но если ваши администраторы полностью настроены против управления полями CLOB в базе данных, это второй вариант.

РЕДАКТИРОВАТЬ:

My_Table ниже, где у вас есть столбец VARCHAR, который вы хотите расширить. Я бы сохранил это в таблице для коротких текстовых полей.

CREATE TABLE MY_TABLE (
INDENTIFER INT,
OTHER_FIELD VARCHAR2(10),
REQUIRED_TEXT VARCHAR(4000),
PRIMERY KEY (IDENTFIER));

Затем напишите запрос, чтобы данные объединялись в две таблицы, упорядочивая их по LINE в поле MY_TEXT. Ваше приложение должно будет разбить строку на 2000 символов и вставить их в порядке строк.

Я бы сделал это в процедуре PL / SQL. Как вставить, так и выбрать. Строки PL / SQL VARCHAR могут содержать до 32 тыс. Символов. Который может или не может быть достаточно большим для ваших нужд.

Но, как и любому другому человеку, отвечающему на этот вопрос, я настоятельно рекомендовал бы довести дело до администратора баз данных, чтобы сделать колонку CLOB. С точки зрения программы это будет BLOB и, следовательно, прост в управлении.

Answer 3

Вы сказали, что нет BLOB или LONG ... но как насчет CLOB? 4 ГБ символьных данных.

Answer 4

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

Более конкретно, какую ошибку вы получаете (от Oracle или вашего языка программирования), когда вы пытаетесь вставить строку из 8000 символов в столбец, определенный как CLOB.

Answer 5

Является ли BFILE жизнеспособным альтернативным типом данных для ваших администраторов баз данных?

Answer 6

BLOB - лучшее решение. Все остальное будет менее удобным и более неудобным для обслуживания.