| # | Name | Goal | Type | Data source ▲ | Last update | License | |
|---|---|---|---|---|---|---|---|
| 861 | Base tables with plenty of data | Find base tables that have 1000 rows or more. | General | system catalog base tables only | 2025-11-07 10:11 | MIT License | View |
| 862 | Base tables with the biggest number of rows | Find the base tables that belong to the top 5 in terms of the number of rows in the table. There should be test data in the tables. | General | system catalog base tables only | 2025-11-07 10:11 | MIT License | View |
| 863 | B-tree index fillfactor has been explicitly set to 90 | This query identifies B-tree indexes where the FILLFACTOR has been explicitly set to 90. Since 90 is the default FILLFACTOR for B-tree indexes in PostgreSQL, this explicit declaration is superfluous. Removing such redundant settings simplifies the schema definition, improves maintainability, and makes intentionally non-default configurations more apparent. | Problem detection | system catalog base tables only | 2025-11-10 09:15 | MIT License | View |
| 864 | Candidate keys and foreign keys of tables that participate in an inheritance hierarchies | Find primary key, unique, foreign key, and exclude constraints that have been defined in tables that participate in an inheritance hierarchy. Do not forget to redefine the constraints that are defined on supertables also on their subtables. | General | system catalog base tables only | 2025-11-07 10:11 | MIT License | View |
| 865 | Cannot register all legal personal names | Find CHECK constraints on base table or foreign table columns that contain data about personal names and apply unnecessary restrictions to the names, rejecting potentially some legal names. Find checks that prohibit a digit or require a letter A-Z. | Problem detection | system catalog base tables only | 2025-11-07 10:11 | MIT License | View |
| 866 | Chains of ON DELETE CASCADE | This query identifies referential paths (chains of foreign key relationships) where every constraint in the path is configured with ON DELETE CASCADE. The analysis is intended to uncover potential transitive deletion risks, where a single DELETE operation on a root table could trigger a catastrophic, cascading data loss across multiple, deeply-nested tables. The length of such chains is a key indicator of architectural fragility. | General | system catalog base tables only | 2025-11-08 10:50 | MIT License | View |
| 867 | CHECK constraints with the cardinality bigger than one | Find multicolumn CHECK constraints. Such constraints must be associated directly with a base table, i.e., these cannot be associated with a domain. Enforce as much data integrity as possible at the database level and prefer declarative constraints to a trigger. | General | system catalog base tables only | 2025-11-07 10:11 | MIT License | View |
| 868 | CHECK constraints with the cardinality bigger than one that involve the same set of columns | CHECK constraints with the cardinality bigger than one that involve the same set of columns. Make sure that there is no duplication. | General | system catalog base tables only | 2025-11-07 10:11 | MIT License | View |
| 869 | Checking the text maximum length with CHECK | This query identifies all base table columns that enforce a maximum value length through the use of a CHECK constraint. It specifically searches for constraint definitions that contain length-calculating functions (such as length(), char_length(), or similar patterns) to provide a comprehensive list of all columns where data length is explicitly managed by a business rule at the database level. | General | system catalog base tables only | 2025-11-13 13:05 | MIT License | View |
| 870 | Column names that make joining more difficult (foreign key column name contains the table name) | This query identifies foreign key columns where the identifier diverges from the referenced candidate key solely due to the redundant inclusion of the referencing table's name (as a prefix or suffix). Such naming redundancy precludes the use of the simplified SQL USING syntax in join operations, forcing the use of the more verbose ON clause. Harmonizing these column names (i.e., making the foreign key name identical to the referenced column name) enables more concise query formulation and improves schema readability. | Problem detection | system catalog base tables only | 2025-12-14 11:56 | MIT License | View |
| 871 | Column names that make joining more difficult (foreign key column name equals the referenced table name) | This query identifies foreign key columns where the identifier is identical to the name of the referenced table. This naming pattern typically results in a mismatch between the foreign key column and the referenced primary key column (e.g., a column named department referencing a table department with a primary key department_id). This mismatch precludes the use of the simplified ANSI SQL USING clause in join operations, necessitating the use of the more verbose ON clause. Harmonizing the column name to match the referenced key enables more concise query formulation. The Example: A table Employees has a column named Department that links to the Department table (where the ID is department_id). The Problem: Because the column is named Department and not department_id, you cannot use the shortcut syntax: JOIN Department USING (department_id). You are forced to write: JOIN Department ON Employees.Department = Department.department_id. |
Problem detection | system catalog base tables only | 2025-12-15 11:07 | MIT License | View |
| 872 | Column names that make joining tables more difficult | This query identifies foreign key columns where the identifier differs from the referenced candidate key identifier. It explicitly excludes self-referencing constraints (recursive relationships), where name divergence is structurally mandatory. The primary objective is to identify opportunities to harmonize column names across the schema. Synchronizing the foreign key name with the referenced column name facilitates the use of the ANSI SQL USING clause in join operations (e.g., JOIN t1 USING (client_id)), which is significantly more concise than the explicit ON predicate required when names differ. | Problem detection | system catalog base tables only | 2025-12-14 11:31 | MIT License | View |
| 873 | Column names that make joining tables more difficult (quite similar names) | This query identifies foreign key columns where the identifier deviates slightly from the referenced candidate key, specifically exhibiting a textual difference (Levenshtein distance) of two to four characters. This range typically captures minor prefixes (e.g., fk_) or suffixes that prevent the use of the concise SQL USING syntax in join operations. The query explicitly excludes self-referencing constraints (recursive relationships), where distinct column names are structurally mandatory. Aligning these names allows for cleaner, more readable query formulation. | Problem detection | system catalog base tables only | 2025-12-14 11:29 | MIT License | View |
| 874 | Column names that make joining tables more difficult (table names) | This query identifies foreign key relationships where the identifier of the referenced column diverges from the foreign key column solely due to the inclusion of the table name. It specifically targets cases where the referenced column name is formed by concatenating the target table name with the target column name (e.g., referenced_col = table_name || '_' || fk_col). This naming redundancy prevents the use of the simplified SQL USING syntax for join operations, necessitating verbose ON clauses. Harmonizing these identifiers by standardizing the naming convention improves schema readability and query conciseness. | Problem detection | system catalog base tables only | 2025-12-14 11:53 | MIT License | View |
| 875 | Column names that make joining tables more difficult (very similar names) | This query identifies foreign key columns where the identifier exhibits a minimal textual deviation (exactly one character) from the referenced candidate key. This specific proximity often indicates a typographical error or a singular/plural inconsistency (e.g., user_id vs users_id). The query explicitly excludes self-referencing constraints, where name divergence is structurally mandatory. Harmonizing these names enables the use of the simplified SQL USING syntax for joins, replacing verbose ON clauses and improving query readability. | Problem detection | system catalog base tables only | 2025-12-14 11:30 | MIT License | View |
| 876 | 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 |
| 877 | 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 |
| 878 | Columns with array or user-defined type | This query identifies columns defined with complex data types, specifically Arrays or User-Defined Types (UDTs). While PostgreSQL supports these advanced features, their indiscriminate use often signals an over-engineered schema. The query serves as a prompt to audit these columns and verify that the complex type is strictly necessary for performance or domain logic, and that a standard relational structure (e.g., scalar types or a child table) would not be a more appropriate and flexible design choice. | General | system catalog base tables only | 2025-12-12 17:23 | MIT License | View |
| 879 | Comments of columns | Find all comments of columns of tables. | General | system catalog base tables only | 2025-11-07 10:11 | MIT License | View |
| 880 | Comments of derived tables | Find comments of derived tables (views and materialized views) that are registered in the system catalog witht a COMMENT statement. Find also comments on their associated objects (columns, triggers, rules). Make sure that the comments give relevant, useful, and correct information. | General | system catalog base tables only | 2025-11-07 10:11 | MIT License | View |