| 301 |
Columns of base tables that hold truth values that do not have a default value although they could have it (Boolean columns) |
Find columns of base tables that have type BOOLEAN. Based on column names these implement a state machine or record agreements. At the same time the columns do not have a default value. There are only two truth values - TRUE and FALSE - in case of two-valued logic. It should be possible to select one of these as the default value of the column. |
Problem detection |
INFORMATION_SCHEMA only |
2025-11-07 10:11 |
MIT License |
View |
| 302 |
Columns of base tables that hold truth values that do not have a default value although they could have it (non-Boolean columns) |
Find columns of base tables that do not have type BOOLEAN but are used to record Boolean values. Based on column names these implement a state machine or record agreements. At the same time the columns do not have a default value. There are only two truth values - TRUE and FALSE - in case of two-valued logic. It should be possible to select one of these as the default value of the column. |
Problem detection |
INFORMATION_SCHEMA+system catalog base tables |
2025-11-07 10:11 |
MIT License |
View |
| 303 |
Columns of base tables with data about postal addresses, file addresses, or web addresses that have an incorrect data type |
Find base table columns that name refers to the possibility that these are used to register file/web addresses. Find the columns where the type refers to the possibility that values in the column are actual files. |
Problem detection |
INFORMATION_SCHEMA only |
2025-11-07 10:11 |
MIT License |
View |
| 304 |
Columns of derived tables that name has been given by the system |
Find columns of derived tables (i.e., views and materialized views) where in the creation statement of the table the name of the column has not been specified, i.e., it is generated by the system. |
Problem detection |
system catalog base tables only |
2025-11-07 10:11 |
MIT License |
View |
| 305 |
Columns of derived tables that name has been given by the system (2) |
Find columns of derived tables (i.e., views and materialized views) where in the creation statement of the table the name of the column has not been specified, i.e., it is generated by the system. |
Problem detection |
system catalog base tables only |
2025-11-07 10:11 |
MIT License |
View |
| 306 |
Columns that have the same name as some domain/type |
Use different names to avoid confusion. |
Problem detection |
INFORMATION_SCHEMA+system catalog base tables |
2025-11-07 10:11 |
MIT License |
View |
| 307 |
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 |
2025-11-07 10:11 |
MIT License |
View |
| 308 |
Columns with a range type that require a better name |
This query identifies columns with a RANGE data type that violate naming conventions. It flags columns whose names do not semantically suggest a range or period, which can create ambiguity and lead to incorrect assumptions when writing queries. |
Problem detection |
INFORMATION_SCHEMA only |
2025-11-07 12:30 |
MIT License |
View |
| 309 |
Columns with BOOLEAN type that do not have a good name |
This query audits the naming conventions of BOOLEAN columns, enforcing a predicate-based naming convention that begins with is_, has_, can_, or on_. It specifically discourages the use of simple adjectival or past participle forms as column names. For instance, is_agreement is the preferred form over agreed, and on_kinnitatud is preferred over kinnitatud. This standard ensures the column's name is an unambiguous true/false question, which improves schema self-documentation and the readability of SQL queries. |
Problem detection |
INFORMATION_SCHEMA+system catalog base tables |
2025-11-13 13:56 |
MIT License |
View |
| 310 |
Columns with exact/floating numeric types have textual default values |
The default value of a column should belong to the type of the column. The system shouldn't conduct unnecessary type casts. |
Problem detection |
INFORMATION_SCHEMA only |
2025-11-07 10:11 |
MIT License |
View |
| 311 |
Columns with only one value |
Find base table columns that contain only one value. Perhaps it is an unnecessary column. Having only one value is most likely inadequate for testing. |
Problem detection |
INFORMATION_SCHEMA+system catalog base tables |
2025-11-07 10:11 |
MIT License |
View |
| 312 |
Completely overlapping foreign keys |
Find completely overlapping foreign keys, i.e., the same set of columns of a table is covered by more than one foreign key constraint. These constraints could refer to the same table/key or different tables/keys. |
Problem detection |
INFORMATION_SCHEMA+system catalog base tables |
2025-11-07 10:11 |
MIT License |
View |
| 313 |
Composite foreign keys with a mix of mandatory and optional columns |
Find composite foreign keys with a mix of mandatory and optional columns. In case of a composite foreign keys all the columns should either optional or mandatory in order to avoid problems with NULLs. |
Problem detection |
system catalog base tables only |
2025-11-07 10:11 |
MIT License |
View |
| 314 |
Composite foreign keys with an incorrect order of columns (ver 1) |
Find composite foreign keys where the order of columns does not correspond to the order of columns in the referenced candidate key. Find composite foreign keys in case of which the foreign key and candidate key consist of columns with the same name but the order of columns in the keys is different. For instance, the query returns information about a foreign key (personal_code, country_code) that refers to the candidate key (country_code, personal_code). In SQL keys are ordered sets of columns. Thus, in case of composite foreign key declarations one has to pay attention that the order of columns in the FOREIGN KEY clause matches the order of columns in the REFERENCES clause. |
Problem detection |
system catalog base tables only |
2025-11-07 10:11 |
MIT License |
View |
| 315 |
Composite foreign keys with an incorrect order of columns (ver 2) |
Find composite foreign keys where the order of columns does not correspond to the order of columns in the referenced candidate key. Find composite foreign keys in case of which the foreign key and candidate key are not the same in terms of data types of the columns. For instance, the query returns information about a foreign key that columns have the types (SMALLINT, INTEGER) that refers to the candidate key that columns have the types (INTEGER, SMALLINT). In SQL keys are ordered sets of columns. Thus, in case of composite foreign key declarations one has to pay attention that the order of columns in the FOREIGN KEY clause matches the order of columns in the REFERENCES clause. |
Problem detection |
system catalog base tables only |
2025-11-07 10:11 |
MIT License |
View |
| 316 |
Constraints that are not redefined in a subtable |
Find primary key, unique, foreign key, and exclude constraints that have been defined in a supertable (parent table) but not in its subtable. Unfortunately, PostgreSQL table inheritance is implemented in a manner that some constraints (CHECK, NOT NULL) are inherited from the supertable but others are not. "All check constraints and not-null constraints on a parent table are automatically inherited by its children, unless explicitly specified otherwise with NO INHERIT clauses. Other types of constraints (unique, primary key, and foreign key constraints) are not inherited." (PostgreSQL documentation) |
Problem detection |
system catalog base tables only |
2025-11-07 10:11 |
MIT License |
View |
| 317 |
Constraints that are not redefined in a subtable and there is no CHECK constraint that compensates this |
Find primary key, unique, foreign key, and exclude constraints that have been defined in a supertable (parent table) but not in its subtable. Additional condition is that in case of the subtable there is no CHECK that permits only one specific value in the constraint column. The presence of such check would make the design acceptable. Unfortunately, PostgreSQL table inheritance is implemented in a manner that some constraints (CHECK, NOT NULL) are inherited from the supertable but others are not. "All check constraints and not-null constraints on a parent table are automatically inherited by its children, unless explicitly specified otherwise with NO INHERIT clauses. Other types of constraints (unique, primary key, and foreign key constraints) are not inherited." (PostgreSQL documentation) |
Problem detection |
INFORMATION_SCHEMA+system catalog base tables |
2025-11-07 10:11 |
MIT License |
View |
| 318 |
Constraints with the same name within the same schema and constraint type |
Find names of foreign key constraints that are used within the same schema more than once. Find names of check constraints that are used within the same schema more than once. Find names of constraint triggers that are used within the same schema more than once. Different things should have different names. But here different constraints have the same name. Also make sure that this is not a sign of duplication. |
Problem detection |
system catalog base tables only |
2025-11-07 10:11 |
MIT License |
View |
| 319 |
Coupling of distinct entity lifecycles via shared state classifiers |
This query identifies a potential domain modeling flaw where multiple distinct entity tables reference a single, shared state classifier table. According to robust design principles, each main entity type should define its own independent state machine and lifecycle. Sharing a classifier creates undesirable coupling; even if the state vocabularies (e.g., 'Active', 'Inactive') appear identical currently, the business logic for distinct entities is likely to diverge over time. Furthermore, reliance on a universal state table often indicates an under-analyzed domain model utilizing overly generic state transitions. |
Problem detection |
system catalog base tables only |
2026-01-19 17:36 |
MIT License |
View |
| 320 |
Cycle in a hierarchy |
There should not be cycles in hierarchies meaning that the parent must always be specified. In this case a parent must reference to a child or to itself, otherwise it cannot be registered. |
Problem detection |
system catalog base tables only |
2025-11-07 10:11 |
MIT License |
View |