Choix judicieux de la clé primaire

Mais dans la table T_Client, que fait-on ? Doit-on également mettre le champ PaysOrigine en clé primaire ? ... Sûrement pas !
Il y a plein de gens qui viennent du même pays, et, de plus, il y a des gens dont on ignore le pays d'origine, et dont le champ est donc vide.
Réfléchissons : y a-t-il un champ qui peut-être défini en clé primaire ?
En d'autres mots, y a-t-il un champ dont il n'est pas possible qu'il y ait deux fois la même chose, et qui soit toujours rempli ?
Le pays, on vient de voir que non..
DateNaissance ? ... Non, plusieurs clients pourraient être nés le même jour, même si ce serait exceptionnel.
La taille ? Non... Le salaire ? Non plus !

NomClient ? Oui, pourquoi pas ! Regardez : ils sont tous remplis et tous différents ... Ou presque ... Eh oui ! Il y a 2 Spielberg !

Du coup, a-t-on vraiment besoin d'une clé primaire dans T_Client ? Pas forcément !

Mais faites ceci : déplacez la Remarque à droite du Prenom, et inscrivez ces deux Remarque pour les deux Spielberg :

Confusion d'enregistrements

Imaginez que vous avez la table sous les yeux, et un client vous appelle au téléphone :

- Bonjour monsieur !
- Bonjour ! Je suis Monsieur Spielberg, et ma commande de 100 Schmilblicks n'est toujours pas arrivée !
- Un instant, je consulte ma super base de données Access, avec ma table T_Client toute neuve dont je suis très fier... Mmmmmm... Ecoutez, je lis que vous avez eu des problèmes de paiement dans le passé !
- Quoi ! Jamais de la vie ! Je vais changer de fournisseur ! Foi de Max Spielberg !

Et il raccroche... Aïe ! Vous vous êtes trompé de client ! C'était Max, pas Steven ! Trop tard !
Que font toutes les entreprises du monde pour identifier leurs clients de manière absolument unique, sans risque de confusion ? ...

Elle vous attribuent un numéro de client !

C'est ce que nous allons faire !