Domains behave as data types with optional built-in constraints. The main advantage of using domains is to have in one place a data type with a specific validation instead of creating separated columns in tables and applying to them the needed constraints to provide correctness when assigning values.
One simple example is an email
column in different tables: the data type, semantics, and validation for this column are the same, thus a neat approach is to create a domain called email
with the needed constraints and assign it as the data type of the columns which requires it. This is the principle of object reuse: no redundancy or repeatedly creating the same object with the same purpose. Additionally, you have only one object to make the changes when needed.
Attribute | Description |
---|---|
Default Value |
The default value for the domain. This field must be formatted according to the data type to be used. |
Not Null |
Indicates if the domain accepts null values or not. |
Data Type |
Data type effectively used by the domain. |
Check constraints |
This tab groups the fields responsible for the creation of check expressions in the domain. |
Name |
The name of the check constraint to be created (on the tab Check constraints ). |
Expression |
The SQL expression assigned to a check constraint that is used to validate any value assigned to the domain (on the tab Check constraints ). |