| # | Name ▲ | Goal | Type | Data source | Last update | License | |
|---|---|---|---|---|---|---|---|
| 81 | Base table columns with DECIMAL (p, s) or NUMERIC (p, s) type | Find base table columns with DECIMAL (p, s) or NUMERIC (p, s) type and make sure that precision p and scale s are not too big or too small. | General | INFORMATION_SCHEMA only | 2025-11-07 10:11 | MIT License | View |
| 82 | Base table columns with one of the following types: BIGINT, INTEGER, TEXT, or VARCHAR without max character length | Each column should have the most appropriate data type. Developers sometimes misuse BIGINT, INTEGER, TEXT or VARCHAR type in places where a type that permits smaller values would be more appropriate and semantically descriptive. | General | INFORMATION_SCHEMA only | 2025-11-07 10:11 | MIT License | View |
| 83 | Base table columns with SMALLINT or BOOLEAN type | Each column should have the most appropriate data type. Developers sometimes forget to use SMALLINT type even if it is logically the best choice. Developers also sometimes forget to use BOOLEAN type and instead invent something. | General | INFORMATION_SCHEMA only | 2025-11-07 10:11 | MIT License | View |
| 84 | Base table columns with the same name and type have different field sizes | Find base table columns that have the same name and type but different field size. | Problem detection | INFORMATION_SCHEMA only | 2025-11-07 10:11 | MIT License | View |
| 85 | Base table columns with the same name have different types | This query identifies semantic inconsistencies across the database schema by finding base table columns that share the same identifier (name) but are defined with differing data types. According to standard data modeling principles, a shared attribute name implies a shared domain concept (e.g., status_code should consistently be an SMALLINT or a CHAR). Discrepancies in data types for homonymous columns (e.g., is_active being BOOLEAN in one table and SMALLINT in another) hinder interoperability, complicate join logic, and confuse developers. | Problem detection | INFORMATION_SCHEMA only | 2025-11-27 11:20 | MIT License | View |
| 86 | Base table columns with the type VARCHAR(1) | The choice of data types should reveal as much as possible about the nature of the data in the column. The type of these columns could be CHAR(1) and they should have a constraint that a value in the column cannot be an empty string. | Problem detection | INFORMATION_SCHEMA only | 2025-11-07 10:11 | MIT License | View |
| 87 | Base table columns with UUID type | Each column should have the most appropriate data type. If one does not want to have in a table the surrogate key that values are generated by using a sequence generator, then one may use instead a column with Universally Unique Identifiers as the key column. | General | INFORMATION_SCHEMA only | 2025-11-07 10:11 | MIT License | View |
| 88 | Base table FILLFACTOR is not 100 | This query generates a list of all base tables where the FILLFACTOR has been explicitly set to a value other than the default of 100. This non-default setting is a deliberate performance tuning decision, intended to reserve free space within table pages to improve the efficiency of UPDATE operations by facilitating HOT updates. The query provides a comprehensive list for administrators to audit these customizations and verify that they are still necessary and appropriate for the current table workload. | General | INFORMATION_SCHEMA+system catalog base tables | 2025-11-10 09:20 | MIT License | View |
| 89 | Base table has a national identification number as a key | Find base table columns that name refers to the possibility that these are used to register national identification numbers (personal codes). Find the columns that constitute a key of a table. This in turn enforces a (restrictive) business rule that all persons of interest come from one country. Make sure that the enforced constraint is valid, i.e., there is indeed such rule in the domain. | General | INFORMATION_SCHEMA+system catalog base tables | 2025-11-07 10:11 | MIT License | View |
| 90 | Base tables and foreign tables that do not have any CHECK constraints on non-foreign key columns | Identify possibly missing CHECK constraints. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2025-11-07 10:11 | MIT License | View |
| 91 | Base tables and foreign tables that have no CHECK constraints | What are the base tables and foreign tables without any associated (directly or through domains) check constraints? A NOT NULL constraint is a kind of CHECK constraint. However, this query does not take into account NOT NULL constraints. | Problem detection | INFORMATION_SCHEMA only | 2025-11-07 10:11 | MIT License | View |
| 92 | Base tables and materialized views without any index | Find base tables and materialized views that do not have any index. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2025-11-07 10:11 | MIT License | View |
| 93 | Base tables created based on a type | Find base tables that have been created based on a composite type and thnk through as to whether it was really needed. | General | system catalog base tables only | 2025-11-07 10:11 | MIT License | View |
| 94 | Base tables that do not have a TOAST table | Find base tables that (due to the types of their columns) do not have an associated TOAST table for storing out-of-line data. | General | system catalog base tables only | 2025-11-07 10:11 | MIT License | View |
| 95 | Base tables that have a surrogate key and all its unique constraints have an optional column | A surrogate key is a primary key that consist of one column. The values of this column do not have any meaning for the user and the system usually generates the values (integers) automatically. In case of defining a surrogate key in a table it is a common mistake to forget declaring existing natural keys in the table. If a key covers an optional column then it does not prevent duplicate rows where some values are missing and other values are equal. Because NULL is not a value and is not duplicate of another NULL the, follwing is possible: CREATE TABLE Uniq(a INTEGER NOT NULL, b INTEGER, CONSTRAINT ak_uniq UNIQUE (a, b)); INSERT INTO Uniq(a, b) VALUES (1, NULL); INSERT INTO Uniq(a, b) VALUES (1, NULL); |
Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2025-11-07 10:11 | MIT License | View |
| 96 | Base tables that have a surrogate key and do not have any uniqueness constraints | This query identifies tables that use a single-column surrogate primary key but lack any other UNIQUE constraints or unique indexes. The absence of additional unique constraints suggests that the natural business key has not been enforced, creating a risk of data duplication that violates business rules. Tables consisting of only a single column are excluded from this check. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2025-11-07 15:29 | MIT License | View |
| 97 | 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 | 2025-11-07 10:11 | MIT License | View |
| 98 | Base tables that have more than five indexes | Find base tables that have more than five indexes. Indexes can be used to increase the speed of queries (SELECT statements). However, the amount of indexes shouldn't be too large. Otherwise it may reduce the speed of operations that are used to modify data. | Problem detection | system catalog base tables only | 2025-11-07 10:11 | MIT License | View |
| 99 | 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 | 2025-11-07 10:11 | MIT License | View |
| 100 | Base tables that have no uniqueness requirement for rows whatsoever | Find base tables without any unique constraints and primary key as well as any unique index, whether it is created explicitly by a developer or automatically by the DBMS. 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+system catalog base tables | 2025-11-07 10:11 | MIT License | View |