Как я могу удалить ограничение «не ноль» в Oracle, если я не знаю имя ограничения?

61

У меня есть база данных, которая имеет ограничение NOT NULL для поля, и я хочу удалить это ограничение. Усложняющим фактором является то, что это ограничение имеет системное имя, и это имя ограничения отличается между производственным сервером, сервером интеграции и различными базами данных разработчиков. Наш текущий процесс - проверить скрипты изменений, а автоматическая задача выполняет соответствующие запросы через sqlplus против целевой базы данных, поэтому я предпочел бы решение, которое можно было бы просто отправить в sqlplus.

В моей собственной базе данных SQL, чтобы отбросить это, будет:

alter table MYTABLE drop constraint SYS_C0044566

Я вижу ограничение при запросе представления all_constraints:

select * from all_constraints where table_name = 'MYTABLE'

но я не уверен, как работать с типом данных SEARCH_CONDITION LONG или как лучше всего динамически удалять искомое ограничение даже после того, как я знаю его имя.

Итак, как я могу создать изменение script, которое может отбросить это ограничение на основе того, что это такое, а не его имя?

EDIT: Ответ @Allan является хорошим, но я обеспокоен (в моем отсутствии опыта Oracle), что не может быть универсально верно, что любое ограничение, которое может иметь сгенерированное системой имя, будет связано с ним способом удаления ограничения без узнав его имя. Верно ли, что всегда будет существовать способ избежать необходимости знать имя с именем системного имени при логическом снижении этого ограничения?

  • 3
    Просто чтобы удовлетворить ваше любопытство: ограничение NOT NULL - единственный тип ограничений в Oracle, который вы можете удалить без необходимости знать имя ограничения. Для всех остальных типов ограничений вам нужно знать имя ограничения.
Теги:
plsql
constraints

5 ответов

134
Лучший ответ
alter table MYTABLE modify (MYCOLUMN null);

В Oracle, а не нулевые ограничения создаются автоматически, если для столбца не задано значение null. Аналогично, они автоматически отбрасываются при изменении столбца, чтобы разрешить null.

Разъяснение пересмотренного вопроса. Это решение применяется только к ограничениям, созданным для столбцов "не нуль". Если вы укажете "Основной ключ" или контрольное ограничение в определении столбца без его именования, вы получите системное имя для ограничения (и индекса для первичного ключа). В таких случаях вам нужно будет узнать имя, чтобы его удалить. Лучший совет - избегать сценария, указав имя для всех ограничений, отличных от "не null". Если вы окажетесь в ситуации, когда вам нужно вообще отказаться от одного из этих ограничений, вам, вероятно, придется обратиться к PL/SQL и таблицам определения данных.

Поделиться
  • 0
    Это кажется слишком хорошим, чтобы быть правдой, но оно определенно подходит для моего текущего случая и просто! Есть ли в оракуле случаи, когда имя ограничения может быть сгенерировано системой, но sql не может быть написано, чтобы избежать такого ограничения?
  • 1
    Спасибо ... получается, что not null ограничения являются единственными системными именами в моей схеме, которые могут повлиять на меня таким образом.
14

Try:

alter table <your table> modify <column name> null;
Поделиться
  • 0
    Оно работает. Спасибо
1

Чтобы обнаружить любые используемые ограничения, используйте следующий код:

-- Set the long data type for display purposes to 500000.

SET LONG 500000

-- Define a session scope variable.

VARIABLE output CLOB

-- Query the table definition through the <code>DBMS_METADATA</code> package.

SELECT dbms_metadata.get_ddl('TABLE','[Table Described]') INTO :output FROM dual;

Это по существу показывает инструкцию create для таблицы ссылок. Зная, как создается таблица, вы можете увидеть все ограничения таблицы.

Ответ, взятый из блога Майкла МакЛаффина: http://michaelmclaughlin.info/db1/lesson-5-querying-data/lab-5-querying-data/ Из своего класса Database Design I.

Поделиться
1

Просто помните, если поле, которое вы хотите сделать допустимым, является частью первичного ключа, вы не можете. Первичные ключи не могут иметь нулевые поля.

Поделиться
0

Я столкнулся с такой же проблемой, пытаясь обойти пользовательское ограничение проверки, которое мне нужно было обновить, чтобы допускать разные значения. Проблема в том, что ALL_CONSTRAINTS не имеет способа определить, к какому столбцу применяются ограничения (-ы). То, как мне удалось это сделать, - это запросить ALL_CONS_COLUMNS вместо этого, затем сбросить каждое из ограничений по их имени и заново создать его.

выберите имя_контакта из all_cons_columns где table_name = [TABLE_NAME]  и column_name = [COLUMN_NAME];

Поделиться

Ещё вопросы

Сообщество Overcoder
Наверх
Меню