Reputation: 5575
I wanted to create an outline constraint for an alter key(NOT NULL + UNIQUE), but I think the NOT NULL constraint can't be placed outline, therefore, I think I have to options:
CHECK(attr IS NOT NULL)
NOT NULL
+ outline constraint UNIQUE(attr)
Is there any difference between set the in-line constraint NOT NULL
to a column and add a constraint CHECK (column IS NOT NULL)
?
Thanks in advance
Upvotes: 2
Views: 6473
Reputation: 107
Yes, there is a significant difference - optimizer treats them differently. Usually, NOT NULL at the column level is preferable from this point of view (may result in better execution plans).
BTW, as for the Jeffrey Kemp comment "NOT NULL is the only type of constraint for which you don't need to know the constraint name in order to remove" - this statement wrong. Primary keys may be dropped without knowing their names, e.g.
create table x(xx number primary key, yy number);
alter table x drop primary key;
alter table x modify xx unique;
alter table x drop unique(xx);
alter table x add unique(xx,yy);
alter table x drop unique(xx,yy);
Upvotes: 1
Reputation: 21
There is some information on the Oracle page here: http://docs.oracle.com/cd/B14117_01/appdev.101/b10795/adfns_co.htm#1006606
Oracle says: "For ease of use, you should always choose to define NOT NULL integrity constraints, instead of CHECK constraints with the IS NOT NULL condition."
Upvotes: 2
Reputation: 231781
Defining a column as NOT NULL
is the preferred approach. That will indicate in the DBA_TAB_COLS
, ALL_TAB_COLS
, and USER_TAB_COLS
data dictionary view, for example, that the column is not NULLABLE
. That would be the conventional approach as well so future developers are much more likely to expect that NOT NULL
constraints are defined on columns that cannot be NULL
.
Just as you could define UNIQUE
constraints along with NOT NULL
constraints rather than creating PRIMARY KEY
constraints, you could define CHECK
constraints rather than NOT NULL
constraints. Both approaches will work in the same way from a functional standpoint. But the data dictionary views will display those approaches differently so tools that rely on the data dictionary may behave slightly differently. And the conventional approaches are much more likely to be something that future developers will see and expect rather than being surprised by.
Upvotes: 6