| 801 | Non-updatable views that have data modification privileges | Be precise and do not give impossible privileges. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2021-02-25 17:29 | MIT License | |
| 802 | Not inherited CHECK constraints that are recreated in the immediate subtable | Find base table CHECK constraints that have been defined as NOT INHERITED but the constraint with the same Boolean expression has been defined in the immediate subtable of the table. | Problem detection | system catalog base tables only | 2021-02-25 17:29 | MIT License | |
| 803 | Not inherited CHECK constraints that cover at least one column | Find CHECK constraints that cover at least one column and that have been defined in a supertable (parent table) but not in its subtables. An entity that belongs to a subtype should also belong to its supertype. If a subtype entity satisfies some constraint, then logically it must also satisfy the constraints of the supertype as well. If CHECK constraints are not inherited, then this is not guaranteed. If you implement subtyping not merely reuse implementation in the subtables, then the subtables must have at least the same CHECK constraints as the supertable. | Problem detection | system catalog base tables only | 2021-02-25 17:29 | MIT License | |
| 804 | ON DELETE CASCADE is probably missing (based on the multiplicity of the relationship) | Find foreign key constraints that completely overlap with a candidate key constraint (primary key or unique constraint) but the foreign key constraint does not have the ON DELETE CASCADE compensating action. In this case there is a foreign key that implements a relationship type between a strong entity type and a weak entity type (1-1 relationship type). Therefore, in this case ON DELETE CASCADE is an appropriate compensating action. | Problem detection | system catalog base tables only | 2021-02-25 17:29 | MIT License | |
| 805 | ON DELETE SET NULL is probably missing | Find implementations of the adjacency list design pattern, where the corresponding foreign key columns are optional but the foreign key constraint does not have ON DELETE SET NULL compensating action. Implement adjacency list correctly. | Problem detection | system catalog base tables only | 2021-02-25 17:29 | MIT License | |
| 806 | One true lookup table | Find tables that contain all (or most) of the classifier values and tables that refer to these. | Problem detection | system catalog base tables only | 2021-02-25 17:29 | MIT License | |
| 807 | Optional base table columns that have a default value that is not the empty string | Find optiona base table columns that have a default value that is not the empty string. Such columns should be mandatory. | Problem detection | INFORMATION_SCHEMA only | 2021-02-25 17:29 | MIT License | |
| 808 | Optional columns before mandatory columns | Find cases where optional columns are before a mandatory column. Place mandatory columns before optional columns to improve comprehensibility of the table. | Problem detection | INFORMATION_SCHEMA only | 2021-02-25 17:29 | MIT License | |
| 809 | Optional composite foreign keys that do not have MATCH FULL specified | Find optional composite foreign keys that do not have MATCH FULL specified. Without MATCH FULL the system will permit partial foreign key values | Problem detection | system catalog base tables only | 2021-02-25 17:29 | MIT License | |
| 810 | Password should not be open text | Find base table columns that name refers to the possibility that these are used to register passwords. Find the columns that have a CHECK constraint that seems to determine the minimal or maximal permitted length of the values in the column. Passwords in a database table must be hashed and salted. Checking the strength of the password by using a check constraint is in this case impossible and the check constraints that try to do it should be removed from the database. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2021-02-25 17:29 | MIT License | |
| 811 | Perhaps a CHECK constraint about the combination of truth values is missing | Find base tables that have at least two columns that have Boolean type and have at least one Boolean column that is not covered by a CHECK constraint involving more than one Boolean column. The Boolean columns possibly mean that we want to record data about states. Often the states depend on each other. For instance, if an order is archived it must be inactive. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2021-02-25 17:29 | MIT License | |
| 812 | Perhaps a CHECK constraint about the order of events is missing | Find base tables that have at least two columns that have DATE or TIMESTAMP (with or without time zone) type and do not have any associated CHECK constraint that involves two or more of these columns. The columns mean that we want to record data about events or processes, which often have a certain order. Hence, in case of each row of such a table the values in these columns must be in a certain order. For instance, the end of a meeting cannot be earlier than the beginning of the meeting. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2021-02-25 17:29 | MIT License | |
| 813 | Perhaps an existing domain could be used to define the properties of a base table column? | Find non-foreifgn key base table columns that have not been defined based on a domain but that have the same properties (data type, field size, default value, and pemisson to use NULLs) as some domain. If you define a domain, then you should try to use it in case of multiple columns. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2021-02-25 17:29 | MIT License | |
| 814 | Perhaps an inconsistent use of NO ACTION and RESTRICT in the foreign key declarations | Find as to whether in case of foreign key constraints both the compensating actions RESTRICT and NO ACTION are used within the same database. If the same thing has to do in different places, then try to do it in the same way. | Problem detection | system catalog base tables only | 2021-02-25 17:29 | MIT License | |
| 815 | Perhaps a relationship should be irreflexive | Enforce all the constraints. A binary relation is called irreflexive, if it does not relate any element to itself. | Problem detection | system catalog base tables only | 2021-02-25 17:29 | MIT License | |
| 816 | Perhaps excessive privileges to use base tables | Find excessive privileges to use base tabes (for others than the owner of the base table). The excessive privileges are all that are not SELECT, INSERT, UPDATE, DELETE. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2021-02-25 17:29 | MIT License | |
| 817 | Perhaps excessive privileges to use views | Find non-SELECT privileges to use views (for others than the owner of the view). Perhaps there should be only the privilege to make queries (SELECT statements based on the views) and data modification takes place by using routines. REFERENCES and TRIGGER privileges are definitely not needed. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2021-02-25 17:29 | MIT License | |
| 818 | Perhaps the precision in case of a base table column with NUMERIC/DECIMAL type is too small | Make sure that in case of using the type DECIMAL/NUMERIC as the type of a base table column the precision (the permitted number of digits in the number) is not too small. For instance, the biggest value in the type NUMERIC(1,1) is 0.9. | Problem detection | INFORMATION_SCHEMA only | 2021-02-25 17:29 | MIT License | |
| 819 | Perhaps the type of a base table column/domain should be BOOLEAN (based on CHECK constraints) | Find base table columns and domains that have a CHECK constraint that limits possible values in a manner that seems to indicate that the permitted values represent truth values, i.e., permitted values are 0/1 or true/false. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2021-02-25 17:29 | MIT License | |
| 820 | Personal names are unique | Find all primary key and unique constraints of base tables that involve at least one column with personal names. Personal names are not unique and these cannot be (usually) used to guarantee uniqueness. Either one has declared a superkey instead of candidate key (i.e., the key contains a column that is not needed for uniqueness) or the key columns have been found incorrectly. | Problem detection | system catalog base tables only | 2021-02-25 17:29 | MIT License | |