| 41 | Depth of relational tree of a table | Depth of relational tree of a table T (DRT(T)) is defined by Piattini et al. (2001) as "the longest referential path between tables, from the table T to any other table in the schema". The result may help to classify the data. If the depth is 0, then probably the table contains classifers. Tables with the largest depth probably contain some extra information about main entities. | Sofware measure | system catalog base tables only | 2020-11-14 16:13 | MIT License | |
| 42 | CHECK constraints that use non-deterministic functions | Discover incorrect usage of non-deterministic functions in CHECK constraints. Find base table columns and foreign table columns that have a CHECK constraint that refers to a non-deterministic function that returns current date/time/timestamp. | General | INFORMATION_SCHEMA only | 2020-11-06 14:51 | MIT License | |
| 43 | Unnecessary domains | Domain is a reusable artifact. Effort of its creation should be paid off by the advantages that it offers. If a domain is used in case of at most one column of a base table or even if it is used in case of more than one column but it does not specify neither a default value nor a check constraint, then there is no point of creating the domain. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2021-02-25 17:29 | MIT License | |
| 44 | Domains with the same name in different schemas | 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. | Problem detection | INFORMATION_SCHEMA only | 2021-02-25 17:30 | MIT License | |
| 45 | Domains that are associated with a sequence generator | 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. | Problem detection | INFORMATION_SCHEMA only | 2021-03-07 21:08 | MIT License | |
| 46 | Derived table on top of another derived table | Do not build multiple levels of derived tables (views and materialized views) because it will hamper evolvability and understandability of the tables. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2021-02-25 17:29 | MIT License | |
| 47 | The same sequence generator is used in case of multiple columns | Do not 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 (for instance the owner column or step), i.e., it increases coupling between tables. By having a shared sequence it is impossible to specify the owner (table column) to the sequence generator. | Problem detection | INFORMATION_SCHEMA only | 2021-03-07 21:07 | MIT License | |
| 48 | Recursive rules that directly modify their home table | Do not cause potentially infinite loops. Recursive rules would fire itself over and over again. Although the system is able to detect these after executing a data modification statement it is better to avoid creating these altogether. | Problem detection | system catalog base tables only | 2022-10-21 15:59 | MIT License | |
| 49 | Recursive triggers that directly modify their home table | Do not cause potentially infinite loops. Recursive trigger fire themselves over and over again. If the system is not able to stop these, then it eventually consumes all the resources of the system. Although the system is able to detect these it is better to avoid creating these altogether. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2021-02-25 17:30 | MIT License | |
| 50 | Incorrect use of non-deterministic functions in CHECK constraints | Do not create a constraint in case of which data that satisfied a constraint c at the registration time suddenly does not satisfy it any more as the time goes by. Find all the check constraints that use non-deterministic functions (now, current_timestamp, localtimestamp, current_date, current_time) in a way that makes this situation possible. Fort instance, localtimestamp(0)>end_date is an example of such constraint. | Problem detection | INFORMATION_SCHEMA only | 2023-11-29 14:59 | MIT License | |
| 51 | Potential duplication of sequence generators | Do not create unnecessary sequence generators. | Problem detection | INFORMATION_SCHEMA only | 2022-11-21 11:01 | MIT License | |
| 52 | Base tables that have only the surrogate key and do not have any other column | Do not create unnecessary tables. If a table has cardinality 1 (one column), then most probably the values in this column should not be system generated unique values. | Problem detection | INFORMATION_SCHEMA only | 2021-03-08 00:41 | MIT License | |
| 53 | Double checking of the maximum character length | Do not duplicate code. In this case a CHECK constraint duplicates the restriction that is already enforced with the help of the declaration of the maximum field size (for instance, VARCHAR(100)). | Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2023-11-18 13:27 | MIT License | |
| 54 | Tables without columns | Do not have in a database elements that are not useful. PostgreSQL permits tables with no columns. Such tables can be used to implement Boolean variables (tables TABLE_DEE and TABLE_DUM). On the other hand, such tables might be a result of database evolution, where developers have not noticed that they have dropped all the columns of a table or have not noticed that they have created such a table in the first place. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2021-02-25 17:29 | MIT License | |
| 55 | Unused schemas | Do not keep in your database elements that are not needed by anybody. These should be put in use or dropped, otherwise these are dead code. | Problem detection | system catalog base tables only | 2021-02-25 17:30 | MIT License | |
| 56 | Unused trigger functions | Do not keep in your database elements that are not needed by anybody. These should be put in use or dropped, otherwise these are dead code. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2021-02-25 17:29 | MIT License | |
| 57 | Using AFTER triggers to enforce constraints | Do not let the system to do extra work. Checking a constraint with an AFTER trigger means that the trigger procedure will be executed after the data modification and if the check fails, then the system has to do extra work to roll back the changes. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2021-02-25 17:29 | MIT License | |
| 58 | UPDATE triggers that maybe execute too often | Do not let the system to do extra work. Ensure that trigger procedures are executed only if there is a real need of that. Find UPDATE triggers that could be executed too often because unneeded executions are not prevented. | Problem detection | INFORMATION_SCHEMA only | 2021-02-25 17:29 | MIT License | |
| 59 | Using BEFORE triggers to log data changes | Do not let the system to do extra work. Logging changes with a BEFORE trigger means extra work for rolling back the changes in case the logged data modification fails. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2021-02-25 17:29 | MIT License | |
| 60 | ROW level BEFORE DELETE and INSTEAD OF DELETE triggers that procedures refer to the row variable NEW | Do not write incorrect code. Variable NEW: "Data type RECORD; variable holding the new database row for INSERT/UPDATE operations in row-level triggers. This variable is null in statement-level triggers and for DELETE operations." (PostgreSQL documentation) | Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2021-12-20 14:25 | MIT License | |