Ok, merci pour la réponse. Je vais regarder cette histoire d'index unique de plus près. Bon, ce n'est de toute façon pas difficile de tester si un login existe déjà avec mon système mais je ne voyais pas trop en quoi ça pouvait poser problème globalement. Bêtement, je n'avais pas pensé aux tables associées.

Comme je le dit dans le tuto en question, un identifiant ne doit pas être une valeur que l'utilisateur connait.

Ton exemple est une illustration parfaite : tu as une table "utilisateur". Immagine que tu mettes à disposition une table "message" qui sont associés à un utilisateur. Dans cette table, il faut que tu mettes la clé primaire de la table utilisateur.
Si tu utilises le login comme clé primaire de la table "utilisateur", lorsque quelqu'un va vouloir changer son login, il va falloir que tu modifies tous les enregistrements de la table "message" pour qu'ils pointent sur le bon enregistrement.

Donc, il faut que tu utilises un identifiant qui est inconnu du public, qui ne peut pas etre modifié, et qui sera le garant à travers le temps de l'identification d'un enregistrement.

Par contre, si ton soucis, c'est de faire en sorte que ta table ne puisses avoir 2 login identiques, il existe la solution des [url=http://dev.mysql.com/doc/refman/5.0/en/create-index.html]index unique[/url] (je t'ai donné le lien vers MySQL, mais c'est implémenté dans tout les SGBD).

Bonsoir,
En parcourant les tutos, je vois qu'il y en a un PHP/SQL qui conseille de ne jamais modifier les identifiants des données.

Et justement, je me posais une question il y a quelques jours : dans le cas d'une table d'utilisateurs qui sont identifiés par un login qui doit être unique (deux utilisateurs ne doivent pas avoir le même login), est-ce qu'il vaut mieux utiliser un id numérique pour chaque utilisateur ou utiliser le champ login comme clé unique de la table ?