Tutoriel SQL de clé primaire - Comment définir une clé primaire dans une base de données

Toute grande histoire commence par une crise d'identité. Luke, le grand Maître Jedi, commence indécis :"Qui suis-je ?" - et comment pourrais-je être quelqu'un d'important ? Il faut Yoda, celui qui possède la Force, pour lui apprendre à exploiter ses pouvoirs.

Aujourd'hui, laisse-moi être ton Yoda.

Nous commencerons par comment choisir une clé primaire, lutter contre une crise d'identité, puis terminerons avec des exemples de code pour créer une clé primaire dans une base de données.

Comment choisir une clé primaire

Vous pensez peut-être que Luke est le seul à avoir une crise d'identité, mais ce n'est pas vrai. Lors de la création d'une base de données, tout est dans une crise d'identité. Et c'est précisément pour cela que nous avons besoin de clés primaires :elles résolvent la crise. Ils nous disent comment trouver tout le monde.

Imaginez que vous êtes le gouvernement et que vous souhaitez identifier numériquement chacun de vos citoyens. Donc, vous créez cette base de données avec tout ce qui les concerne :

First Name
Last Name
Passport Number

Vous choisissez le numéro de passeport comme clé primaire - l'identité de chacun. Vous pensez que c'est tout ce dont vous avez besoin puisque le passeport contient l'adresse et tout le reste. Vous savez que les numéros de passeport sont uniques, alors vous vous sentez bien et mettez en œuvre ce système.

Puis, quelques années plus tard, vous découvrez une affreuse vérité :le pays tout entier est confronté à une crise d'identité.

Chaque fois que le passeport de quelqu'un expire, il en obtient un nouveau. Leur identité change. D'autres systèmes continuent d'utiliser les anciens numéros de passeport, ils pointent donc désormais vers des personnes fantômes.

L'unicité ne suffit pas. La valeur ne doit pas changer pendant toute la durée de vie de la ligne.

Et puis, vous trouvez qu'il y a des gens qui n'ont même pas de passeport. Vous ne pouvez pas les saisir dans votre système, car les clés primaires ne peuvent pas être NULL . Comment pouvez-vous identifier quelqu'un avec un NULL clé ?

Chaque ligne doit avoir un identifiant. Les valeurs NULL ne sont pas autorisées.

La prochaine itération consiste à trouver un identifiant qui ne change pas dans le temps et que tout le monde possède. En Inde, cela s'avère être la carte Adhaar. Aux États-Unis, le numéro de sécurité sociale.

Si vous créez une base de données, faites-en vos clés primaires.

Parfois, vous n'avez pas une telle clé. Considérez un pays qui n'a pas encore de numéro de sécurité sociale et qui souhaite créer un enregistrement numérique de chaque citoyen. Ils pourraient créer un nouveau SSN, ou ils pourraient simplement tirer parti de la puissance des bases de données et utiliser une clé de substitution.

Une clé de substitution n'a pas d'équivalent dans le monde réel. C'est juste un nombre dans une base de données. Donc, vous avez ce tableau dans le nouveau pays :

userID
First Name
Last Name
Passport Number

Les numéros de passeport sont uniques. Chaque fois que vous souhaitez obtenir l'identifiant d'un utilisateur, vous pouvez l'obtenir via le numéro de passeport.

L'ID utilisateur ne change jamais. Le numéro de passeport peut changer - mais il est toujours unique, vous obtenez donc toujours le bon utilisateur. L'ID utilisateur est un substitut pour un numéro de sécurité sociale inexistant dans ce pays.

Fait amusant :le numéro de passeport ici est également une clé de candidat. Cela aurait pu être la clé primaire, si elle n'a jamais changé. Il s'agit d'une distinction de logique métier.

Le principal point à retenir est le suivant :Chaque fois que vous choisissez une clé primaire, pensez à une crise d'identité . Est-il possible que quelqu'un change d'identifiant à l'avenir ? Pouvons-nous entrer dans un état où plusieurs personnes ont le même identifiant ?

J'utilise les gens comme exemple, car cela rend l'identité plus claire - nous savons que chaque personne est censée avoir une identité. Transférez cette réflexion dans vos bases de données. Tout a une identité, c'est exactement pourquoi vous avez besoin de clés primaires.

Remarque :Parfois, il est possible et souhaitable d'utiliser plusieurs colonnes ensemble comme clé primaire. Il s'agit d'une clé composite.

Essayons maintenant de définir les clés primaires avec des exemples de code réels. Il y a deux choses à faire ici :premièrement, vous identifierez la clé primaire. Ensuite, vous apprendrez la syntaxe pour le définir dans une base de données.

Un exemple concret

Disons que vous dirigez une startup d'expédition, un peu comme Flexport. Vous avez des colis qui doivent être acheminés d'un endroit à un autre et des navires qui les transportent. De plus, vous avez des clients qui commandent ces packages.

Vous pensez que vous aurez besoin d'un tableau pour les clients, un pour les colis et un pour le transport, indiquant quel colis se trouve où en ce moment.

Réfléchissez aux colonnes dont vous aurez besoin et à ce que devrait être la clé primaire. Si vous étiez ingénieur chez Flexport, c'est une vraie question que vous auriez à résoudre. Rien n'est donné, tout se découvre dans le monde réel.

Compte tenu de ces informations, je concevrais ces tables comme suit :

Customers: first_name, last_name, email, address (for deliveries to their location)
Packages: weight, content
Transportation: <package_primary_key>, Port, time

Il nous manque les clés primaires. Pensez-y avant de lire plus loin.

Pour le package, je choisirai un substitut ID de package. J'aurais pu essayer de lister tous les attributs du colis :poids, volume, densité, âge. Ils identifieraient le colis de manière unique, mais cela est très difficile à faire dans la pratique. Les gens ne s'en soucient pas, ils s'intéressent juste au fait que le colis se rende d'un endroit à un autre.

Il est donc logique de créer un nombre aléatoire et de l'utiliser comme ID. C'est exactement la raison pour laquelle FedEx, UPS et tous les services de livraison utilisent des codes-barres et des identifiants. Ce sont des clés de substitution générées pour suivre les colis.

Pour le client, je choisirai un substitut N ° de client. Là encore, j'avais la possibilité de choisir, par exemple, le numéro de sécurité sociale de mes clients. Mais les clients ne veulent pas partager cela avec moi juste pour que je puisse leur envoyer quelque chose. Ainsi, nous générons une clé en interne, ne communiquons pas cette clé à nos clients et continuons à les appeler CustomerNo. 345681.

Histoire amusante :Je connais quelques entreprises où ils ont exposé ce CustomerNo, et les clients ont insisté pour qu'ils obtiennent le numéro 1. C'était assez hilarant ; les ingénieurs ont en fait dû changer leur code frontal en :if (cust == 345681) print(1);

Pour le transport, je choisirai un composite PackageID+Port+heure. C'est un peu plus intéressant. J'aurais pu créer un substitut ici aussi, et ça marcherait tout aussi bien.

Mais c'est là que réside la magie de l'indexation. Les clés primaires obtiennent automatiquement un index, ce qui signifie que la recherche est beaucoup plus efficace que les clés primaires.

Lorsque vous effectuez une recherche dans cette base de données, la plupart des requêtes seront de la forme "Où est ce paquet ?". En d'autres termes, étant donné ce PackageID, indiquez-moi le port et l'heure auxquels il se trouve actuellement. J'aurais besoin d'un index supplémentaire sur PackageID si je ne l'ai pas dans ma clé primaire.

Est-ce que ça sonne bien? Dernière étape, définissons ces 3 tables en SQL. La syntaxe varie légèrement selon la base de données que vous utilisez.

Définir les clés primaires dans MySQL

CREATE TABLE customers
( customerID  INT(11) NOT NULL AUTO_INCREMENT PRIMARY KEY,
  last_name   VARCHAR(30) NOT NULL,
  first_name  VARCHAR(25) NOT NULL,
  email		  VARCHAR(50) NOT NULL,
  address     VARCHAR(300)
);

CREATE TABLE packages
( packageID  INT(15) NOT NULL AUTO_INCREMENT,
  weight     DECIMAL (10, 2) NOT NULL,
  content    VARCHAR(50),
  CONSTRAINT packages_pk PRIMARY KEY (packageID) # An alternative way to above,
  # when you want to name the constraint as well.
);

CREATE TABLE transportation
( package 	INT(15) NOT NULL,
  port  	INT(15) NOT NULL,
  time	 	DATE NOT NULL,
  
  PRIMARY KEY (package, port, time),
  FOREIGN KEY package
  	REFERENCES packages(packageID)
	ON DELETE RESTRICT    # It's good practice to define what should happen on deletion. In this case, I don't want things to get deleted.

);

Définir les clés primaires dans PostgreSQL

CREATE TABLE customers
( customerID  SERIAL NOT NULL PRIMARY KEY, # In PostgreSQL SERIAL is same as AUTO_INCREMENT - it adds 1 to every new row.
  last_name   VARCHAR(30) NOT NULL,
  first_name  VARCHAR(25) NOT NULL,
  address     TEXT,
  email		  VARCHAR(50) NOT NULL
);

CREATE TABLE packages
( packageID  SERIAL NOT NULL,
  weight     NUMERIC NOT NULL,
  content    TEXT,
  CONSTRAINT packages_pk PRIMARY KEY (packageID) # In PostgreSQL, this alternative way works too.
);

CREATE TABLE transportation
( package 	INTEGER NOT NULL,
  port  	INT(15) NOT NULL,
  time	 	DATE NOT NULL,
  
  PRIMARY KEY (package, port, time),
  
  FOREIGN KEY package
  	REFERENCES packages(packageID)
	ON DELETE RESTRICT    # It's good practice to define what should happen on deletion. In this case, I don't want things to get deleted.

);

Ce n'est pas très différent, n'est-ce pas ? Une fois que vous maîtrisez les bases, vous pouvez l'appliquer à presque toutes les bases de données en jetant un coup d'œil à la documentation. La clé est de savoir quoi chercher !

Bonne chance, jeune padawan.

Vous avez aimé ça ? Vous aimerez peut-être aussi Ce que j'ai appris d'un ingénieur logiciel senior