Создать таблицу с контрольными ограничениями

Не могли бы вы объяснить, как результаты будут отличаться (каковы преимущества) между двумя операциями таблицы CREATE?Создать таблицу с контрольными ограничениями

Вариант № 1

CREATE TABLE sch.address_type (
    address_type_cd VARCHAR2(50 BYTE) NOT NULL CONSTRAINT sch_2002 CHECK ("address_type_cd" IS NOT NULL), 
    desc_txt VARCHAR2(100 BYTE) NOT NULL CONSTRAINT sch_2003 CHECK ("DESC_TXT" IS NOT NULL), 
    rec_creat_ts TIMESTAMP DEFAULT CURRENT_TIMESTAMP NOT NULL CONSTRAINT sch_2001 CHECK ("REC_CREAT_TS" IS NOT NULL), 
    CONSTRAINT pk_address_type PRIMARY KEY (address_type_cd) 
);

Вариант № 2

CREATE TABLE sch.address_type (
    address_type_cd VARCHAR2(50 BYTE) NOT NULL, 
    desc_txt VARCHAR2(100 BYTE) NOT NULL, 
    rec_creat_ts TIMESTAMP DEFAULT CURRENT_TIMESTAMP NOT NULL, 
    CONSTRAINT pk_address_type PRIMARY KEY (address_type_cd) 
);

Благодаря

источник

2017-02-21 JonathanSK

Ограничения 'check' совершенно не нужны. Почему вы включили их? –

Разница в том, что если вы измените таблицу, чтобы удалить обозначение NOT NULL в столбцах, ограничения проверки из первой версии все равно будут на месте. Это вызовет много путаницы. Теперь: Это вопрос, который вы хотели спросить, или вы хотели спросить что-то еще? А именно, возможно, в первом запросе, который вы делали ** не ** означает иметь «NOT NULL», а вместо этого требовали только ограничения «CHECK»? – mathguy

Я использую инструмент сравнения между двумя средами баз данных, а одна среда отображается как первый оператор create, а второй - тот, у которого нет контрольных ограничений. Было любопытно, было ли преимущество для первого - казалось бы, избыточным было иметь как в первом примере ... – JonathanSK

Глядя ограничения, созданных с помощью запроса:

SELECT constraint_name, constraint_type, search_condition 
FROM ALL_CONSTRAINTS 
WHERE table_name = 'ADDRESS_TYPE';

Вариант 1:

CONSTRAINT_NAME  C SEARCH_CONDITION    
-------------------- - ------------------------------ 
PK_ADDRESS_TYPE  P 
SYS_C0010366   C "ADDRESS_TYPE_CD" IS NOT NULL 
SYS_C0010367   C "DESC_TXT" IS NOT NULL 
SYS_C0010368   C "REC_CREAT_TS" IS NOT NULL 
SCH_2002    C address_type_cd IS NOT NULL 
SCH_2003    C "DESC_TXT" IS NOT NULL 
SCH_2001    C "REC_CREAT_TS" IS NOT NULL

Вариант 2:

CONSTRAINT_NAME  C SEARCH_CONDITION    
-------------------- - ------------------------------ 
PK_ADDRESS_TYPE  P 
SYS_C0010373   C "ADDRESS_TYPE_CD" IS NOT NULL 
SYS_C0010374   C "DESC_TXT" IS NOT NULL 
SYS_C0010375   C "REC_CREAT_TS" IS NOT NULL

Вариант 3:

CREATE TABLE address_type (
    address_type_cd VARCHAR2(50 BYTE) CONSTRAINT address_type__cd__pk PRIMARY KEY, 
    desc_txt  VARCHAR2(100 BYTE) CONSTRAINT address_type__desc__nn NOT NULL, 
    rec_creat_ts TIMESTAMP   DEFAULT CURRENT_TIMESTAMP 
            CONSTRAINT address_type__rct__nn NOT NULL 
);

Имеет ограничения:

CONSTRAINT_NAME   C SEARCH_CONDITION    
------------------------- - ------------------------------ 
ADDRESS_TYPE__CD__PK  P 
ADDRESS_TYPE__DESC__NN C "DESC_TXT" IS NOT NULL 
ADDRESS_TYPE__RCT__NN  C "REC_CREAT_TS" IS NOT NULL

Итак:

Вариант 1 создает 7 ограничения которых Есть 3 пары дублирующих ограничений (где каждый пара имеет имя пользователя и системное имя)
Op Тион 2 создает 4 ограничения (Избавление от дублированных пользователя имени ограничений, в результате чего системы назвали ограничение)
Варианта 3 создает только три ограничения - это ограничение NOT NULL ненужно на PRIMARY KEY колонке, и это также именует NOT NULL ограничения.

Все варианты дадут тот же эффективный результат. Именование ваших ограничений полезно при отладке (даже ограничения NOT NULL)

источник

2017-02-22 00:34:48 MT0

Оба заявления делают ту же функцию, но в первом запросе вы делаете ненужных усилий. i.e address_type_cd VARCHAR2(50 BYTE) NOT NULL такой же, как CONSTRAINT sch_2002 CHECK ("address_type_cd" IS NOT NULL),. Оба из них означают, что следует значение в поле и не может быть равно NULL

источник

2017-02-21 20:39:38

Создать таблицу с контрольными ограничениями

ответ

Смежные вопросы