Filter Queries
Found 1056 queries.
- All the queries about database objects contain a subcondition to exclude from the result information about the system catalog.
- Although the statements use SQL constructs (common table expressions; NOT in subqueries) that could cause performance problems in case of large datasets, it shouldn't be a problem in case of the relatively small amount of data in the system catalog of a database.
#641. Optimistic locking routines lacking execution feedback
INFORMATION_SCHEMA+system catalog base tablesThis query identifies SQL routines that implement optimistic concurrency control via the xmin system column but fail to provide an execution status to the invoker. Specifically, it flags functions that perform UPDATE or DELETE operations filtered by xmin (a version check) but do not return information regarding the operation's success (e.g., a row count or a BOOLEAN status). This is a critical logic flaw; if a concurrency conflict occurs (the row was modified by another transaction), the operation yields zero rows. Without a return value, the failure is silent, leaving the calling application unaware that the data modification did not occur.
#642. Optional base table columns that have a default value
INFORMATION_SCHEMA onlyThis 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.
#643. Optional base table columns that participate in a UNIQUE constraint or index
INFORMATION_SCHEMA+system catalog base tablesFind optional base table columns that participate in a UNIQUE constraint or index. Each base table has one or more candidate keys. One of these is usually selected to be the primary key, other are called alternate keys. To enforce an alternate key one should define a UNIQUE constraint and determine that all the key columns are mandatory (NOT NULL) just like the primary key columns are mandatory. Make sure that the NOT NULL constraint is not missing on these columns.
#644. Optional columns before mandatory columns
INFORMATION_SCHEMA onlyFind cases where optional columns are before a mandatory column. Place mandatory columns before optional columns to improve comprehensibility of the table.
#645. Optional composite foreign keys that do not have MATCH FULL specified
system catalog base tables onlyFind optional composite foreign keys that do not have MATCH FULL specified. Without MATCH FULL the system will permit partial foreign key values
#646. Optional non-foreign key base table columns that participate in a UNIQUE constraint or index
INFORMATION_SCHEMA+system catalog base tablesFind optional base table columns that participate in a UNIQUE constraint or index but do not participate in a foreign key constraint. Each base table has one or more candidate keys. One of these is usually selected to be the primary key, other are called alternate keys. To enforce an alternate key one should define a UNIQUE constraint and determine that all the key columns are mandatory (NOT NULL) just like the primary key columns are mandatory. Make sure that the NOT NULL constraint is not missing on these columns.
#647. Overlapping non-function based indexes that have the same leading column with the same operator class
system catalog base tables onlyFind non-function based indexes (both unique and non-unique) that duplicate each other because their first column is identical and the operator class that is used in case of the first column is identical. Include unique indexes that support a constraint (primary key, unique, exclude), i.e., these indexes have been automatically created due to the constraint declaration.
#648. Overloading may cause runtime error
INFORMATION_SCHEMA+system catalog base tablesRoutines in the same schema that have the same name and that have parameters with different types or different number of parameters are not considered to be in conflict at the creation time. However, if defaults are provided in the definition of parameters, then these routines might be conflict during runtime.
#649. Overly strict CHECK constraints on personal names
INFORMATION_SCHEMA onlyThis query identifies potentially overly strict CHECK constraints applied to base or foreign table columns that store personal names. It highlights validation rules that might inadvertently block valid legal names.
#650. Oversized classifier code data types
INFORMATION_SCHEMA+system catalog base tablesThis query identifies classifier tables where the code column uses a data type that accommodates unnecessarily large values for reference data. Specifically, it flags code columns defined as integer, bigint, or varchar(n) where n > 10.
#651. Pairs of base tables that have at least two columns with the same names and data types
INFORMATION_SCHEMA onlyWhat 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.
#652. Pairs of non-key column name and type pairs that have in different base tables a different default value
INFORMATION_SCHEMA+system catalog base tablesFind 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)
#653. Pairs of non-key column name and type pairs that have in some base tables a default value and some cases not
INFORMATION_SCHEMA+system catalog base tablesFind 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)
#654. Parameter name contains the routine name
INFORMATION_SCHEMA+system catalog base tablesFind parameters that have the same name as the routine. The names may have different uppercase/lowercase characters. Make sure that the naming style is consistent.
#655. Parameter name is the same as the name of a used column
INFORMATION_SCHEMA+system catalog base tablesIf the name of a routine parameter and the name of a column of a table that is used in the routine are the same, then it makes it more difficult to understand the code.
#656. Parameter name is the same as the name of a used column (ver 2)
INFORMATION_SCHEMA+system catalog base tablesIf the name of a routine parameter and the name of a column of a table that is used in the routine are the same, then it makes it more difficult to understand the code.
#657. Parameter name is the same as the routine name
INFORMATION_SCHEMA+system catalog base tablesFind parameters that have the same name as the routine. The names may have different uppercase/lowercase characters. Make sure that the naming style is consistent.
#658. Password is unique
INFORMATION_SCHEMA+system catalog base tablesFind columns that potentially contains passwords and that participate in a unique constraint or index
#659. Password should not be open text
INFORMATION_SCHEMA+system catalog base tablesFind base table columns that name refers to the possibility that these are used to register passwords. Find the columns that have a CHECK constraint that seems to determine the minimal permitted length of the values in the column. Passwords in a database table must be hashed and salted. Checking the strength of the password by using a check constraint is in this case impossible and the check constraints that try to do it should be removed from the database.
#660. Perhaps 0 instead of o
INFORMATION_SCHEMA+system catalog base tablesFind the names of database objects where 0 sign is perhaps used instead of o.
| # | Name(activate to sort ascending) | Goal(activate to sort ascending) | Type(sorted ascending, activate to sort descending) | Data source(activate to sort ascending) | Last update(activate to sort ascending) | License | Actions |
|---|---|---|---|---|---|---|---|
| 641 | Optimistic locking routines lacking execution feedback | This query identifies SQL routines that implement optimistic concurrency control via the xmin system column but fail to provide an execution status to the invoker. Specifically, it flags functions that perform UPDATE or DELETE operations filtered by xmin (a version check) but do not return information regarding the operation's success (e.g., a row count or a BOOLEAN status). This is a critical logic flaw; if a concurrency conflict occurs (the row was modified by another transaction), the operation yields zero rows. Without a return value, the failure is silent, leaving the calling application unaware that the data modification did not occur. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | MIT (opens in new tab) | View (opens in new tab) | |
| 642 | 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 | MIT (opens in new tab) | View (opens in new tab) | |
| 643 | Optional base table columns that participate in a UNIQUE constraint or index | Find optional base table columns that participate in a UNIQUE constraint or index. Each base table has one or more candidate keys. One of these is usually selected to be the primary key, other are called alternate keys. To enforce an alternate key one should define a UNIQUE constraint and determine that all the key columns are mandatory (NOT NULL) just like the primary key columns are mandatory. Make sure that the NOT NULL constraint is not missing on these columns. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | MIT (opens in new tab) | View (opens in new tab) | |
| 644 | 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 | MIT (opens in new tab) | View (opens in new tab) | |
| 645 | Optional composite foreign keys that do not have MATCH FULL specified | Find optional composite foreign keys that do not have MATCH FULL specified. Without MATCH FULL the system will permit partial foreign key values | Problem detection | system catalog base tables only | MIT (opens in new tab) | View (opens in new tab) | |
| 646 | Optional non-foreign key base table columns that participate in a UNIQUE constraint or index | Find optional base table columns that participate in a UNIQUE constraint or index but do not participate in a foreign key constraint. Each base table has one or more candidate keys. One of these is usually selected to be the primary key, other are called alternate keys. To enforce an alternate key one should define a UNIQUE constraint and determine that all the key columns are mandatory (NOT NULL) just like the primary key columns are mandatory. Make sure that the NOT NULL constraint is not missing on these columns. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | MIT (opens in new tab) | View (opens in new tab) | |
| 647 | Overlapping non-function based indexes that have the same leading column with the same operator class | Find non-function based indexes (both unique and non-unique) that duplicate each other because their first column is identical and the operator class that is used in case of the first column is identical. Include unique indexes that support a constraint (primary key, unique, exclude), i.e., these indexes have been automatically created due to the constraint declaration. | Problem detection | system catalog base tables only | MIT (opens in new tab) | View (opens in new tab) | |
| 648 | Overloading may cause runtime error | Routines in the same schema that have the same name and that have parameters with different types or different number of parameters are not considered to be in conflict at the creation time. However, if defaults are provided in the definition of parameters, then these routines might be conflict during runtime. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | MIT (opens in new tab) | View (opens in new tab) | |
| 649 | Overly strict CHECK constraints on personal names | This query identifies potentially overly strict CHECK constraints applied to base or foreign table columns that store personal names. It highlights validation rules that might inadvertently block valid legal names. | Problem detection | INFORMATION_SCHEMA only | MIT (opens in new tab) | View (opens in new tab) | |
| 650 | Oversized classifier code data types | This query identifies classifier tables where the code column uses a data type that accommodates unnecessarily large values for reference data. Specifically, it flags code columns defined as integer, bigint, or varchar(n) where n > 10. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | MIT (opens in new tab) | View (opens in new tab) | |
| 651 | 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 | MIT (opens in new tab) | View (opens in new tab) | |
| 652 | 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 | MIT (opens in new tab) | View (opens in new tab) | |
| 653 | 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 | MIT (opens in new tab) | View (opens in new tab) | |
| 654 | Parameter name contains the routine name | Find parameters that have the same name as the routine. The names may have different uppercase/lowercase characters. Make sure that the naming style is consistent. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | MIT (opens in new tab) | View (opens in new tab) | |
| 655 | Parameter name is the same as the name of a used column | If the name of a routine parameter and the name of a column of a table that is used in the routine are the same, then it makes it more difficult to understand the code. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | MIT (opens in new tab) | View (opens in new tab) | |
| 656 | Parameter name is the same as the name of a used column (ver 2) | If the name of a routine parameter and the name of a column of a table that is used in the routine are the same, then it makes it more difficult to understand the code. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | MIT (opens in new tab) | View (opens in new tab) | |
| 657 | Parameter name is the same as the routine name | Find parameters that have the same name as the routine. The names may have different uppercase/lowercase characters. Make sure that the naming style is consistent. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | MIT (opens in new tab) | View (opens in new tab) | |
| 658 | Password is unique | Find columns that potentially contains passwords and that participate in a unique constraint or index | Problem detection | INFORMATION_SCHEMA+system catalog base tables | MIT (opens in new tab) | View (opens in new tab) | |
| 659 | Password should not be open text | Find base table columns that name refers to the possibility that these are used to register passwords. Find the columns that have a CHECK constraint that seems to determine the minimal permitted length of the values in the column. Passwords in a database table must be hashed and salted. Checking the strength of the password by using a check constraint is in this case impossible and the check constraints that try to do it should be removed from the database. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | MIT (opens in new tab) | View (opens in new tab) | |
| 660 | Perhaps 0 instead of o | Find the names of database objects where 0 sign is perhaps used instead of o. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | MIT (opens in new tab) | View (opens in new tab) |