Discussion :

[dorian53]

Bonjour,

Où faut-il la validation des données d'une entité ?

Exemple avec une classe User.
Une fonction qui vérifie que l'e-mail est du bon format et qu'il n'est pas utilisé.

Dans l'entité ou dans le service ?

Merci

[CinePhil]

La maîtrise des données, c'est le boulot du SGBD.

À lire : l'article de SQLPro sur les bases de données épaisses.

[dorian53]

Merci pour cet article très intéressant.

C'est vrai que je reste perplexe sur la pratique de cette théorie.
Valider les données au niveau le plus bas est le plus sécurisé mais j'ai du mal à croire que ce soit la solution la plus performante, bien au contraire.

Est ce que cette théorie est applicable avec MySQL ?
Comment faudrait-il faire ?

Prénons un cas tout simple, valider une inscription utilisateur avec :
- un login, unique en base, alphanumérique, entre 3 et 20 caractères
- un email, unique en base, format valide, certains domaines refusés

Comment gérer cette validation côté base ? Par procédure stockée ?
Comment surtout remonter toutes les erreurs à la fois ?

Merci

[CinePhil]

L'unicité d'un login ou d'une adrel est garantie par un index de type UNIQUE chez MySQL. Il n'y a rien d'autre à programmer que de mettre un index UNIQUE sur ces colonnes. Il faut juste gérer le retour d'erreur de MySQL dans le programme si la contrainte d'unicité est violée.

La solution "vérification par le programme" de ces contraintes d'unicité consisterait à lancer une requête vers le SGBD avec le login et l'adrel saisis par l'utilisateur pour vérifier s'ils exsitent déjà en BDD. Quitte à lancer une requête, autant n'en lancer qu'une : celle d'insertion du nouvel utilisateur en BDD !

En plus, le temps que cette vérification soit faite par le programme, un autre utilisateur peut venir avec le même login !

MySQL étant en retard de 20 ans avec certains éléments de la norme SQL, il ne connaît pas les contraintes CHECK qui permettrait de vérifier la longueur du login et sa composition alphanumérique.

Il faut, chez MySQL mettre alors en oeuvre un trigger before insert, qui vérifiera en même temps a validité de l'adrel.

Donc avec la méthode "contrôle par la BDD" :
- le programme envoie la requête d'insertion ;
- le SGBD fait toutes les vérifications et renvoie un code d'erreur ou l'identifiant auto-incrémenté de l'utilisateur créé.
- le programme gère le code d'erreur reçu ou continue sa tâche de succès de la création de l'utilisateur.

Avec la méthode "contrôle par le programme" :
- le programme vérifie que le login ne comporte que des lettres et des chiffres, ainsi que sa longueur et agit en conséquence (là, pas de requête vers le serveur) ;
- le programme vérifie le format de l'adrel et agit en conséquence (là, pas de requête vers le serveur) ;
- le programme envoie une requête pour demander si le domaine de l'adrel saisi par l'utilisateur n'est pas interdit ;
- le SGBD renvoie un comptage de ligne trouvée ;
- le programme lit et gère le résultat ;
- le programme lance une requête pour vérifier l'unicité du login et de l'adrel ;
- le SGBD renvoie un comptage de lignes trouvées, de 0 (ok) à N (ko).

Qu'est-ce qui est le plus rapide et le plus sûr ?

[dorian53]

1/ Entièrement d'accord pour l'unicité d'envoyer l'insert directement mais beaucoup plus sceptique par un traitement sgbd trigger si la base n'est pas nécessaire. La c'est plus lourd et long de traverser toutes les couches.

2/ Si on se concentre sur l'exemple est-il techniquement possible qu'un trigger remonte 3 erreurs :
- problème format d'un champ
- email non unique
- login non unique

3/ Pour les deux unicités, la requête ne bloque t-elle pas dès la 1ere contrainte violée?

Merci

[CinePhil]

1/ Entièrement d'accord pour l'unicité d'envoyer l'insert directement mais beaucoup plus sceptique par un traitement sgbd trigger si la base n'est pas nécessaire. La c'est plus lourd et long de traverser toutes les couches.

Quelles couches ?

2/ Si on se concentre sur l'exemple est-il techniquement possible qu'un trigger remonte 3 erreurs :
- problème format d'un champ
- email non unique
- login non unique

Oui avec quelques astuces. Il faudrait retrouver la discussion où ce genre de choses avait été abordé dans le forum MySQL.
Un autre SGBD serait je crois capable de RAISE ERROR naturellement mais MySQL étant ce qu'il est, il faut ruser.

3/ Pour les deux unicités, la requête ne bloque t-elle pas dès la 1ere contrainte violée?

Il est fort possible en effet que MySQL ne renvoie qu'un seul message d'erreur, sur la première contrainte d'unicité qu'il trouve violée.

Je ne sais pas si c'est pareil avec les autres SGBD.

[dorian53]

Quelles couches ?

À titre d'exemple :
- Présentation
- Service
- Métier
- DAO

Merci en tout cas pour cette réponse, il y a des choses intéressantes à prendre.

D'autres avis ?