PostgreSQL Query Catalog

Find all CHECK constraints (except NOT NULL) of domains that are not associated with any column.

Find domains that specify a default values and columns that are defined based on the domain. Make sure that there are no unsuitable default values.

Find all domains.

Find base table columns that have the same name as the domain name or the data type name of the column. The names may have different uppercase/lowercase characters. Columns, domains, and types are different concepts in SQL and perhaps it is better to use different names in case of these.

Find simple check constraints (involve one column) that are associated with a base table column instead of the domain of the column. Common checks of data in columns that share the same domain should be described at the level of domain not at the level of columns.

Use different names to avoid confusion.

This query identifies database objects of the same type within the same schema (or container) that have identical names (and parameters in case of routines) when ignoring case. In SQL databases, this confusing scenario typically occurs when mixing quoted (case-sensitive) and unquoted (case-insensitive) identifiers. For example, a single schema could contain both a table named "Client" and another table named client.

Find domains that have been used to define one or more base table non-foreign key columns and all the columns have the same default value that is associated directly with the column not with the domain. Write as little code as possible. If possible, move things "before the brackets" so to say. In this case it means declaring the default value at the level of the domain and not at the level of base table columns. An exception is when the domain is used to define foreign key columns. In this case, it would be appropriate to define the default value at the column level (because different foreign keys could have different default values).

Find domains that have been defined based on another domain. Do not specify domains based on existing domains. This would unnecessarily increase dependencies and complexity.

Find column descriptions that are candidates for describing a domain.

This query identifies violations of modular design principles within user-defined domains. It detects CHECK constraints belonging to a domain where the constraint's name incorporates the identifier of a specific base table that utilizes that domain. Since domains are intended as reusable, abstract data types applicable across multiple entities, embedding a specific implementation context (like a table name) into the constraint's identifier creates semantic coupling. This makes the domain confusing to reuse in other contexts. Constraint identifiers should reflect the inherent logic of the domain (e.g., check_email_format), not the object to which it is applied.

Find domain check constraint names that are used more than once (within the same schema or in different schemas). Different things should have different names. However, here different constraints have the same name. Also make sure that this is not a sign of duplication of domains.

Find domains that declare a default value and that are used in case of multiple foreign key constraints that point to different tables. Domains should be used in a manner that does not cause unnecessary coupling of concerns. For instance, let us assume that columns client_state_type_code of table Client (that is used to implement the relationship with table Client_state_type) and worker_state_type_code of table Worker (that is used to implement the relationship with table Worker_state_type) have been defined based on the same domain. It the domain has a default value, then it determines the initial state of both clients and workers. However, it must be possible to determine the initial state independently in case of clients and workers.

Use different names to avoid confusion.

Find names of domains that contain the name of the table that column the domain specifies. Domains are reusable artifacts that one should be able to use in case of different base tables. Thus, it is inappropriate to use the name of a particular table in the name of the domain.

Domains are reusable artifacts. By associating a domain with a sequence generator, one essentially starts to share sequence generators between tables. It may cause a potential performance bottleneck by having a shared resource. By having a shared sequence it is not possible to change properties of sequences of different tables independently, i.e., it increases coupling between tables.

Domains are like words that can be used to construct generalized claims about the real world (table predicates). Better not to duplicate the words in the dictionary.

Find for each domain the number of usages in base tables. The less you have managed to reuse domains in case of different columns, the more you have wasted your time by creating the domains.

The same domain should not have multiple CHECK constraints with exactly the same Boolean expression. Do remember that the same task can be solved in SQL usually in multiple different ways. Thus, the exact copies are not the only possible duplication.

Find base table columns that have both default value determined through a domain and default value that is directly attached to the column. Do not duplicate specifications of default values to avoid confusion and surprises. If column and domain both have a default value, then in case of inserting data the default value that is associated directly with the column is used.