| 1 | All columns of a base table have a default value | Find base tables where all the columns have a default value. | Problem detection | INFORMATION_SCHEMA only | 2021-02-25 17:29 | MIT License | |
| 2 | Base table column name is the same as its domain name | 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. | Problem detection | INFORMATION_SCHEMA only | 2021-02-25 17:29 | MIT License | |
| 3 | Base table column of personal names has questionable properties | Find base table columns that name refers to the possibility that these are used to register personal names. Although there are very long personal names the general approach is to register a shortened version of these. Thus, a large field size is not a good idea because it would cause usability and security problems. There are persons who only have one name (mononymous persons). Database design must take it into account. | Problem detection | INFORMATION_SCHEMA only | 2022-10-29 20:35 | MIT License | |
| 4 | Base table column of sums of money has too big or small scale | Find base table columns that name refers to the possibility that these are used to register data about prices/sums of money. Find the columns that have decimal type but have a too big (bigger than six) or a too small scale (zero). The selection of field size must be precise and should take into account the possible data in the column. | Problem detection | INFORMATION_SCHEMA only | 2021-03-21 11:45 | MIT License | |
| 5 | Base table columns with the same name and type have different field sizes | Find base table columns that have the same name and type but different field size. | Problem detection | INFORMATION_SCHEMA only | 2021-03-28 16:59 | MIT License | |
| 6 | Base tables and foreign tables that do not have any CHECK constraints on non-foreign key columns | Identify possibly missing CHECK constraints. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2021-02-25 17:29 | MIT License | |
| 7 | Base tables that have more than five indexes | Find base tables that have more than five indexes. Indexes can be used to increase the speed of queries (SELECT statements). However, the amount of indexes shouldn't be too large. Otherwise it may reduce the speed of operations that are used to modify data. | Problem detection | system catalog base tables only | 2022-10-21 10:33 | MIT License | |
| 8 | Candidate key columns that have a static default value | Find base table columns that are covered by a primary key or a unique constraint and that probably have a static default value. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2023-11-12 11:32 | MIT License | |
| 9 | Coalesce/Concat need at least two arguments | Find user-defined routines and derived tables (views/materialized views) that have a subquery that contain an invocation of Coalesce or Concat function with just one argument. You should use the Coalesce and Concat functions correctly by invoking these with at least two arguments. If one invokes these functions with one argument, then the functions will return the input value. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2021-12-08 11:49 | MIT License | |
| 10 | Column names that make joining tables more difficult | Find foreign keys where the name of the foreign key column and the corresponding primary key/unique column is different. Exclude foreign key columns that refer to the key of the same table because within each named table column names must be different. Simplify writing queries that have to join data from multiple base tables. If the columns that participate in the join condition have the same name, then one can use the USING syntax. | Problem detection | system catalog base tables only | 2023-11-08 13:56 | MIT License | |
| 11 | Columns of base tables that hold truth values but do not have a default value (Boolean columns) | Find columns of base tables that have type BOOLEAN but do not have a default value. There are only two truth values - TRUE and FALSE - in case of two-valued logic. Often it should be possible to select one of these as the default value of a column that has BOOLEAN type. | Problem detection | INFORMATION_SCHEMA only | 2023-11-09 13:14 | MIT License | |
| 12 | Columns of base tables that hold truth values but do not have a default value (non-Boolean columns) | Find non-foreign key columns of base tables that probably (based on the column name) contain values that represent truth values but do not have a default value. There are only two truth values - TRUE and FALSE - in case of two-valued logic. It could be possible to select one of these as the default value in case of the columns. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2021-03-20 14:08 | MIT License | |
| 13 | Columns that have the same name as their domain/type | Find the columns that name is the same as the name of the type of the column or the domain of the column. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2022-11-30 13:04 | MIT License | |
| 14 | Cycles in relationships | Find as to whether foreign key constraints between tables form a cycle. For instance, if table C refers to table B, table B refers to table A, table A refers to table C and all the foreign key columns are mandatory, then one cannot add data to the tables. Is cycle value in the result should not contain value TRUE. One should check manually as to whether the foreign key columns are mandatory or optional. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2021-11-28 15:15 | MIT License | |
| 15 | Deferrable foreign key constraint with a RESTRICT compensating action | Find deferrable foreign key constraint with ON UPDATE RESTRICT or ON DELETE RESTRICT compensating action. Referential actions are carried out before, and are not part of, the checking of a referential constraint. Deferring a referential constraint defers the checking of the of the constraint (a ) but does not defer the referential actions of the referential constraint. In PostgreSQL the essential difference between NO ACTION and RESTRICT is that NO ACTION allows the check to be deferred until later in the transaction, whereas RESTRICT does not. Thus RESTRICT could result with the failure of data modification where in case of NO ACTION the modification would succeed. | Problem detection | system catalog base tables only | 2021-10-08 11:29 | MIT License | |
| 16 | Derived table presents the same data in the same way as a single base table | Find derived tables (views and materialized views) that present data from one base table without adding columns, renaming columns, changing the order of columns, removing columns, or restricting rows. Perhaps something is missing from the subquery of the derived table. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2023-12-25 12:15 | MIT License | |
| 17 | Derived table uses a function to get data from another table | Find views that use a function to get data from another table. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2023-11-24 14:36 | MIT License | |
| 18 | Different foreign key column names in case of referencing the same candidate key | Find the cases when the names of columns in different foreign keys that reference to the same candidate key are different. If different names reflect different roles, then it is legitimate. However, there could also be accidental differences that makes it more difficult to use the database. | Problem detection | system catalog base tables only | 2021-03-12 11:21 | MIT License | |
| 19 | Different ways how to find default timestamp values | Find all the default values of base table, view, and foreign table columns that are expressions invoking a function that returns a timestamp. Do it only if there are different expressions, i.e., there could be possible inconsistencies. | Problem detection | INFORMATION_SCHEMA only | 2023-12-08 16:08 | MIT License | |
| 20 | Do not always depend on one's parent - column names are ot sufficiently different | Find where a hierarchical structure is implemented in a base table by adding a foreign key that refers to a candidate key of the same table. Find only cases where the candidate key and foreign key column names are very similar (Levenshtein distance shorter than four). | Problem detection | system catalog base tables only | 2022-11-26 17:19 | MIT License | |