| 121 |
JSON type instead of JSONB type |
"In general, most applications should prefer to store JSON data as jsonb, unless there are quite specialized needs, such as legacy assumptions about ordering of object keys." (https://www.postgresql.org/docs/current/datatype-json.html) |
Problem detection |
INFORMATION_SCHEMA only |
2025-11-07 10:11 |
MIT License |
View |
| 122 |
Mixing different mechanisms to generate surrogate values |
Use the same mechanism of generating surrogate key values throughout the database. The use of SERIAL notation/explicitly creating a sequence generator and declaration of a column as an identity column will cause the creation of an external and internal sequence generator, respectively. Nevertheless, one should try to stick with using one of the mechanisms in order to cause less confusion. "If you do something a certain way, do all similar things in the same way." (Robert C. Martin, Clean Code) |
Problem detection |
INFORMATION_SCHEMA only |
2025-11-07 10:11 |
MIT License |
View |
| 123 |
Mixing the use of TEXT and VARCHAR type in case of base table columns |
Declaring a column to have the type TEXT or the type VARCHAR (without the maximum number of characters) has the same end result in terms of what data can be recorded in the column. Nevertheless, one should try to stick with using one of the type names in order to cause less confusion. "If you do something a certain way, do all similar things in the same way." (Robert C. Martin, Clean Code) |
Problem detection |
INFORMATION_SCHEMA only |
2025-11-07 10:11 |
MIT License |
View |
| 124 |
Multiple columns in the same base table that are associated with a sequence generator |
Find base tables where multiple columns are associated with a sequence generator. Do not create unnecessary sequence generators. If one uses in a table a surrogate key, then it is enough to have one column where the values are generated by using a (external or internal) sequence generator. |
Problem detection |
INFORMATION_SCHEMA only |
2025-11-07 10:11 |
MIT License |
View |
| 125 |
Non-foreign key columns that have no associated CHECK constraints |
Find what are the base table columns that are not foreign key columns and that have no associated CHECK constraints? Perhaps some CHECK constraints are missing. |
Problem detection |
INFORMATION_SCHEMA only |
2025-11-07 10:11 |
MIT License |
View |
| 126 |
NOT NULL constraint via CHECK instead of NOT NULL constraint |
Find columns where the NOT NULL constraint has been added with the help of an explicit CHECK constraints instead of a NOT NULL constraint. One should note that internally NOT NULL constraints are treated as a kind of CHECK constraints. Nevertheless, the design should be consistent (i.e., NOT NULL is enforced with the same way in different places). |
Problem detection |
INFORMATION_SCHEMA only |
2025-11-07 10:11 |
MIT License |
View |
| 127 |
Optional base table columns |
Find optional base table columns, i.e., columns that permit NULLs. Are you sure you want to allow NULLs in these columns? |
General |
INFORMATION_SCHEMA only |
2025-11-07 10:11 |
MIT License |
View |
| 128 |
Optional base table columns that have a default value |
This query identifies columns that are both NULLable and have a DEFAULT value. This configuration represents a semantic contradiction: the DEFAULT clause implies that a value should always exist for the column, while the absence of a NOT NULL constraint explicitly permits the absence of a value. The presence of a DEFAULT strongly suggests the column's business logic requires a value, and therefore it should be defined with a NOT NULL constraint to enforce this consistently and make the schema's intent unambiguous. |
Problem detection |
INFORMATION_SCHEMA only |
2025-11-12 19:04 |
MIT License |
View |
| 129 |
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 |
2025-11-07 10:11 |
MIT License |
View |
| 130 |
Optional foreign key columns |
Find foreign key columns that do not have the NOT NULL constraint. It is better to limit the use of NULLs and optional columns due to the problems that it causes in interpreting the query results, making queries, and enforcing constraints. In addition, one should check as to whether this kind of design is consistent with the multiplicities in the conceptual data model. |
General |
INFORMATION_SCHEMA only |
2025-11-07 10:11 |
MIT License |
View |
| 131 |
Pairs of base tables that have at least two columns with the same names and data types |
What are the pairs of base tables that have at least two columns with the same names and data types. The tables might violate the principle of orthogonal design and hence might facilitate uncontrolled data redundancy over different tables. |
Problem detection |
INFORMATION_SCHEMA only |
2025-11-07 10:11 |
MIT License |
View |
| 132 |
Percentage of optional columns in each base table |
What is the percentage of optional columns (that permit NULLs) in case of each base table? It is better to prohibit the use of NULLs in as many columns as possible. Otherwise the results of queries may be misleading. |
Sofware measure |
INFORMATION_SCHEMA only |
2025-11-07 10:11 |
MIT License |
View |
| 133 |
Perhaps an unnecessary default value (the empty string or a string that consists of only whitespace) of a base table column/domain |
This query identifies table columns and domains that are configured with a semantically void DEFAULT value. It specifically flags defaults that are an empty string ('') or a string consisting solely of whitespace characters (e.g., spaces, newlines). This practice is a design flaw because it automatically populates the database with non-substantive data, which can lead to application-level bugs when code does not explicitly check for such "blank" values in addition to NULL. |
Problem detection |
INFORMATION_SCHEMA only |
2025-11-12 15:02 |
MIT License |
View |
| 134 |
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 |
2025-11-07 10:11 |
MIT License |
View |
| 135 |
Perhaps a state machine is implemented with timestamp columns |
Find implementations of state machines that uses a set of columns with a timestamp type. |
Problem detection |
INFORMATION_SCHEMA only |
2025-11-07 10:11 |
MIT License |
View |
| 136 |
Perhaps a too simplified state machine |
Find base table columns with Boolean type that name refers to the possibility that these are used to register as to whether an entity is currently in active state or not. Find the base tables that have exactly one Boolean column. During the system design one should find all the possible states of an entity type that influence the behavior of the information system. Data as to whether an entity is in one of these states should be in the database. Having only two states - active/inactive - is sometimes a too big simplification. |
Problem detection |
INFORMATION_SCHEMA only |
2025-11-07 10:11 |
MIT License |
View |
| 137 |
Perhaps checking of file extension is incorrect |
Find check constraints of tables that use a regular expression to check as to whether a registered string ends with an appropriate file extension. However, the expression does not put the dot sign into the square brackets nor does have the escape character \before it, i.e., it is interpreted as a single character not as the dot sign in the expression. In regular expressions the dot (.) matches any single character except the newline character. |
Problem detection |
INFORMATION_SCHEMA only |
2025-11-07 10:11 |
MIT License |
View |
| 138 |
Perhaps default value 'infinity' is missing |
Find optional base table columns that have a timestamp type and do not have a default value. |
Problem detection |
INFORMATION_SCHEMA only |
2025-11-07 10:11 |
MIT License |
View |
| 139 |
Perhaps incorrect column name (based on default values) |
This query identifies a semantic mismatch between column definitions and their identifiers. It flags base table columns that are configured with a DEFAULT value of CURRENT_USER or SESSION_USER (indicating they store user identity) but whose names fail to reflect this purpose. Specifically, it searches for columns lacking semantic cues such as "user", "login", "owner", or "by" in their names. This obscuration reduces schema self-documentation, as developers cannot intuitively determine that the column is intended for audit or ownership tracking. |
Problem detection |
INFORMATION_SCHEMA only |
2025-12-14 13:09 |
MIT License |
View |
| 140 |
Perhaps incorrect default vale |
Find columns of base tables that have default value CURRENT_USER. |
Problem detection |
INFORMATION_SCHEMA only |
2025-11-07 10:11 |
MIT License |
View |