Pular para o conteúdo principal

SQL: Primary Key constraint name convention


Demand

ALWAYS name forein keys constraints as "fk_{LocalTableName}_{LocalColumnName}_{DestinationTableName}_{DestinationFieldName}"


Description

We use this convention to easily identify the source of the failure, especially in schema updates.

When creating a CONSTRAINT we create its name starting with the string "fk", followed by the full name of the source table, also called local table or child table, followed by the name of the column used in the source table to store the value to be searched for later in the target table, the name of the target table and finally the name of the field in the target table. All separated by "_" (underline).

Examples

1:  CREATE TABLE customers (
2:      id INT NOT NULL,
3:      name VARCHAR(100) NOT NULL,
4:      user_id INT NULL COMMENT 'if the customer have a system login it will be refernced here',
5:     PRIMARY KEY (id),
6:     CONSTRAINT `fk_customers_user_id_users_user_id` 7:        FOREIGN KEY (`user_id`) 8:     
REFERENCES `users` (`id`) ON DELETE NO ACTION ON UPDATE NO ACTION 9: );


Examples Explanation

Sample of an error output using MariaDB

1: SQLSTATE[HY000]: General error: 1833 Cannot change column 'id': used in a foreign key constraint 'fk_customers_user_id_users_user_id' of table 'mydb.customers'


Sample of an error output using MS-SQLServer

1: The UPDATE statement conflicted with the REFERENCE constraint "fk_customers_user_id_users_user_id". The conflict occurred in database "mydb", table "mydb.customers", column 'user_id'.



Comentários

Postagens mais visitadas deste blog

Article: Preventing Database Gridlock: Recognizing and Resolving Deadlock Scenarios

Learn how deadlocks occur in database systems, understand their impact on performance, and discover practical techniques for identifying potential deadlock scenarios in your SQL code.

Demystifying MySQL ALTER TABLE ALGORITHM: INPLACE vs INSTANT vs COPY

  Schema evolution is one of the trickiest aspects of database management. For developers and DBAs, the dreaded ALTER TABLE command often conjures fears of downtime, locks, and performance bottlenecks. But MySQL offers a powerful word! The "ALGORITHM" modifier that determines how schema changes are executed. In this article, we’ll break down the three key algorithms "INPLACE", "INSTANT", and "COPY" to help you understand their trade-offs, performance implications, and even some unconventional ways to use them. Whether you’re optimizing for zero downtime or experimenting with stress testing, this guide will give you practical insights and real-world strategies. IMPORTANT: Check your MySQL version: In MySQL 8.0+, many table changes are instantaneous, and the command modifications presented here are only available in this and later versions. Understanding the ALGORITHM Modifier When you run an ALTER TABLE in MySQL, you can specify the algorithm, lik...

Collation Confusion: Demystifying VARBINARY vs VARCHAR in Database Design

Have you ever wondered why your database sorts strings differently than expected, or why a seemingly simple query delivers "quirky" results? If you’ve worked with databases like MySQL, PostgreSQL, or SQL Server, you’ve likely stumbled across the mysterious world of collation and the subtle but critical differences between VARBINARY and VARCHAR data types. In this article I hope to unravel these concepts for you, explore how collation shapes database behavior, and dive into an experimental case study to reveal surprising insights. Whether you’re a developer or a database engineer, this deep dive will equip you with practical knowledge to avoid common pitfalls and optimize your database designs. Let’s get started! What Is Collation and Why Does It Matter? Collation refers to the set of rules a database uses to compare and sort character strings. It governs how strings are ordered (e.g., is “Apple” less than “apple”?), how accents are treated (e.g., does “é” equal “e”?), and eve...