Goal | Naming of foreign key and referenced candidate key columns should be consistent. It cannot be so that in one table a value is labeled "id" like some surrogate key value and in another it "turns" into human-usable "code" or vice versa. An example: Person(person_id, name) Primary Key (person_id) E_mail_address(e_mail_address_id, person_code, address) Primary Key (e_mail_address_id) Foreign key (person_code) References Person (person_id) |
Type | Problem detection (Each row in the result could represent a flaw in the design) |
Reliability | High (Few or no false-positive results) |
License | MIT License |
Fixing Suggestion | Rename the columns. In case of the example: Person(person_id, name) Primary Key (person_id) E_mail_address(e_mail_address_id, person_id, address) Primary Key (e_mail_address_id) Foreign Key (person_id) References Person (person_id) |
Data Source | system catalog only |
SQL Query |
|
This query belongs to the following collections:
Name | Description |
---|---|
Find problems automatically | Queries, that results point to problems in the database. Each query in the collection produces an initial assessment. However, a human reviewer has the final say as to whether there is a problem or not . |
This query is classified under the following categories:
Name | Description |
---|---|
Inconsistencies | Queries of this catergory provide information about inconsistencies of solving the same problem in different places. |
Naming | Queries of this category provide information about the style of naming. |
Relationships between tables | Queries of this category provide information about how database tables are connected to each other and whether such connections have been explicitly defined and whether it has been done correctly. |