UNIQUE constraints specify that the associated column must contain unique values. Vantage implements UNIQUE constraints as either a unique primary index, a unique secondary index, or as a single-table join index.
The following rules
apply to UNIQUE constraints:
- UNIQUE constraints must be specified with a NOT NULL attribute specification.
Otherwise, a single null can be inserted into a uniquely constrained column. The semantics of a unique null "value" are uncertain and violate the intent of the uniqueness constraint.
- UNIQUE constraints can be defined at column-level (simple)
or at table-level (composite).
The following table explains the column limits for column-level and table-level primary key constraints.
| UNIQUE Constraint | Definition Level |
|---|---|
| Simple (defined on a single column) | Column. You can define a simple UNIQUE constraint at table-level, but there is no reason to do so. |
| Composite (defined on multiple columns) | Table. Defining a table-level constraint is the only way you can create a multicolumn UNIQUE constraint. |
- Column-level UNIQUE constraints refer only to the specified columns.
- Table-level UNIQUE constraints can be defined on multiple columns by specifying a column name list.
- A table-level UNIQUE constraint can be defined on a maximum of 64 columns.
- A maximum of 100 table-level constraints can be defined for any table.
- You can define a UNIQUE constraint for a column-partitioned table.
- If a row-level security-protected table is defined with a UNIQUE constraint, enforcement of the constraint does not run any security policy defined for the table. UNIQUE constraints are applicable to all rows in a row-level security-protected table, not just to user-visible rows.
- You cannot define a UNIQUE constraint on a row-level security constraint column of a row-level security-protected table.