Bonjour à tous,

J'aimerais votre avis sur quelquechose...

Prenons un exemple simple : une table user avec user_id (INT, auto_increment et PK) et user_nom (VARCHAR (100)) et un formulaire d'inscription.

Pour éviter les doublons, il y a la méthode "classique" :

$req = mysql_query("SELECT COUNT(user_id) FROM user WHERE user_nom='".$_POST['user_nom']."'");

if(mysql_result($req) > 0) {
     // il y a déjà quelqu'un avec ce nom
}
elseif() {
     // requete d'insertion
     echo "insertion ok";
}

Ce que je me demande, si c'est il n'est pas plus "propre" et logique d'une certaine façon d'ajouter à la table un INDEX UNIQUE contenant user_nom et de faire :

if(!(mysql_query("INSERT INTO ...")) {
     if(mysql_errno() == 1062) {
           // il y a déjà quelqu'un avec ce nom
     }
}
else {
     echo "insertion ok";
}

Ainsi on évite à coup sûr le doublon car c'est MySQL qui fait lui-même la vérification grâce à l'index unique.

Qu'en pensez-vous?

La méthode est tout aussi valable, simplement il te faudra gérer le retour qui sera un message d'erreur MySQL au lieu d'un nombre issu d'un comptage. Mais au final, le résultat sera le même.

Je sais que dans ma boite, beaucoup de contrôle d'erreur "classique" sont exclusivement gérés par la base de donnée avec gestion des retours d'erreurs.
Les clés primaires, étrangères etc... font parti intégrante des processus et pas seulement là pour garantir la "pureté" des données.
Après chacun ses méthodes, j'ai été moi-même assez réticent à fonctionner comme ça mais résultat pas mal de contrôle basique ne sont plus implémentés côté applicatif.
Certains me diront qu'il y a plus de risques certes, mais le gain en temps doit être intéressant (dev + prod).
Qu'en pensez-vous?