| 681 | Do not always depend on one's parent (INFORMATION_SCHEMA) | Find where a hierarchical structure is implemented in a base table by having a foreign key that refers to a candidate key of the same table. This design is called adjacency list. | General | INFORMATION_SCHEMA only | 2021-03-07 10:57 | MIT License | |
| 682 | The number of tables by schema, by type, and in total | Find the number of tables (base, foreign, and derived) in different schemas. | Sofware measure | INFORMATION_SCHEMA+system catalog base tables | 2021-03-07 10:57 | MIT License | |
| 683 | Do not use dual-purpose foreign keys | Find cases where the same column of a base table T is used to record references to multiple base tables. In addition, one has to add additional column to T for holding metadata about the parent table, referenced by the current row. | Problem detection | INFORMATION_SCHEMA only | 2021-03-07 10:56 | MIT License | |
| 684 | Small tables | Find tables that have one column or zero columns. | General | INFORMATION_SCHEMA+system catalog base tables | 2021-03-07 10:52 | MIT License | |
| 685 | Pairs of non-key column name and type pairs that have in different base tables a different default value | Find non-key base table columns with the same name and type that have different default values. Be consistent. Columns with the same name and type shouldn't probably have different default values in case of different tables. "If you do something a certain way, do all similar things in the same way." (Robert C. Martin, Clean Code) | Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2021-03-05 21:01 | MIT License | |
| 686 | Pairs of non-key column name and type pairs that have in some base tables a default value and some cases not | Find non-key base table columns with the same name and type that have in some cases a default value and some cases not. Be consistent. Columns with the same name and type should probably either always have a default value in case of different tables or never have a default value in case of different tables. "If you do something a certain way, do all similar things in the same way." (Robert C. Martin, Clean Code) | Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2021-03-05 21:01 | MIT License | |
| 687 | Perhaps a redundant column (based on sequence generators) | Find base tables where more than one column gets the default value by using the sequence generator mechanism. | Problem detection | INFORMATION_SCHEMA only | 2021-03-05 09:42 | MIT License | |
| 688 | Perhaps the type of a base table column/domain should be INTEGER/SMALLINT/BIGINT (based on sequence generators) | Specify for each column/domain a right data type that takes into account expected values in the column/domain. Find base table columns and domains that refer to the nextval function by using the default value mechanism but do not have the type INTEGER, SMALLINT, or BIGINT. This check is performed in case of identity columns: ERROR: identity column type must be smallint, integer, or bigint. | Problem detection | INFORMATION_SCHEMA only | 2021-03-04 11:24 | MIT License | |
| 689 | Different non-surrogate key default values | Find the different default values that implement something other than a surrogate key. | General | INFORMATION_SCHEMA only | 2021-03-04 10:31 | MIT License | |
| 690 | The proportion of using different integer types as types of base table columns | Find the number of base table columns that use different integer types (SMALLINT, INTEGER, BIGINT) and their proportion from the overall set of columns that use an integer type. | Sofware measure | INFORMATION_SCHEMA only | 2021-03-03 12:41 | MIT License | |
| 691 | Base tables where certainly registration time is not recorded | Find base tables that do not have any column with a timestamp type. In such tables certainly registration time is not recorded. Make sure as to whether recording registration time is necessary. | General | INFORMATION_SCHEMA only | 2021-02-26 00:41 | MIT License | |
| 692 | All the non-primary key columns are optional | Find base tables where all he non-primary key columns are optional. Avoid too many optional columns. You have to be extra careful with NULLs in case of formulating search conditions of data manipulation statements. | Problem detection | INFORMATION_SCHEMA only | 2021-02-25 17:30 | MIT License | |
| 693 | A table has the same name as a routine | Find table names that are the same as some routine name. Use different names to avoid confusion. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2021-02-25 17:30 | MIT License | |
| 694 | Base tables that have a unique constraint but not the primary key | A common style is to declare in each base table one of the candidate keys as the primary key. All the other candidate keys would be alternate keys that will be enforce with the help of UNIQUE + NOT NULL constraints. | Problem detection | INFORMATION_SCHEMA only | 2021-02-25 17:30 | MIT License | |
| 695 | Base tables that have neither a unique constraint nor the primary key | Find base tables without any unique constraints and the primary key. In such tables there are no restrictions for recording duplicate rows. Each row represents a true proposition about the real world. It does not make the proposition truer if one presents it more than once. Moreover, duplicate rows increase data size. Without keys the DBMS lacks vital information about data in the database that it can internally use to choose better execution plans and in this way improve performance of database operations. The only legitimate reason of such a table is if it is an abstract table that is used to define common columns of subtables. | Problem detection | INFORMATION_SCHEMA only | 2021-02-25 17:30 | MIT License | |
| 696 | Base tables where all the columns are optional | Find base tables where all the columns are optional, i.e., permit NULLs. In such tables can be rows with no identity value and thus indistinguishable from other rows. | Problem detection | INFORMATION_SCHEMA only | 2021-02-25 17:30 | MIT License | |
| 697 | Base tables, which statistics is probably not up to date | Find base tables where statistics has not been collected at all or it has been lastly collected more than 40 days ago. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2021-02-25 17:30 | MIT License | |
| 698 | Cannot accommodate all the fractional seconds in case of table columns | The precision of a timestamp type of a column must be able to accommodate all the fractional seconds of the default value of the column. Find table columns with the type timestamp without time zone(m) or timestamp with time zone(m) that have a default value LOCALTIMESTAMP(n) or CURRENT_TIMESTAMP(n) WHERE n>m. | Problem detection | INFORMATION_SCHEMA only | 2021-02-25 17:30 | MIT License | |
| 699 | CHAR columns have a default value that length is shorter from the character maximum length of the column | Choose a suitable data type, field size, and default value. If the default value is shorter from the character maximum length, then spaces will be added to the end of the registered value. | Problem detection | INFORMATION_SCHEMA only | 2021-02-25 17:30 | MIT License | |
| 700 | CHECK constraints with IS NULL | Find CHECK constraints to one column (associated with a base table directly or through domain) that check that the value is missing (IS NULL). Write as simple constraint definitions as possible. By default columns are optional, i.e., they permit NULLs. NULL in a column means that checking of a CHECK constraint on the column results with UNKNOWN. CHECK constraints permit rows in case of which checking results with TRUE or UNKNOWN. In case of a CHECK constraint there is no need to check separately that a value in the column could be missing, i.e., be NULL. Thus, for instance, instead of writing CHECK (price>0 OR price IS NULL) write CHECK (price>0). | Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2021-02-25 17:30 | MIT License | |