Discussion :

[passie]

Bonjour à tous,
Sur les champs des tables, je met certaines contraintes (NULL/NOT NULL mais aussi des contraintes via CHECK) en plus des contraintes liées à la déclaration du type de données.
Je suis en train de développer une interface php pour alimenter ma base via des formulaires, je me pose donc forcement la question de la vérification de la saisie utilisateur (aprés post ou pas d'ailleur !), je me demande donc pourquoi je serait contraint de refaire des tests sur la bonne saisie sachant que les contraintes sont réellement fixée lors de la création de la table et éventuellement modifiées mais toujours côté SQL.
peut t'on par requête récupérer les contraintes de colonnes et/ou tester en sql ce que donnerai l'insertion en base, ceci pour les null par expl mais aussi pour les check.
Expl si mon champ est déclaré de type integer NOT NULL avec un check en tre 0 et 10. puis je soit :

1. récupérer le détail de ses contraintes
2. tester l'insertion par requête

Je cherche à éviter d'avoir à refaire le boulot côté php ou javascript avec des critéres identiques mais non synchronisés, si changement il faut aussi le faire dans les deux sources (SQL et PHP).
Merci d'avance pour votre avis sur la question et sur qlq pistes éventuelles.

Peut être via PLPGSQL pour me dire si oui le champ est valide ou pas, sans forcement savoir laquelles des contraintes n'est pas respéctée mais au moins que ce champ est problématique

[CinePhil]

Dans ton cas, si les contraintes sont déjà implémentées en BDD, il faut que le code de l'application récupère et traite les erreurs retournées par le SGBD, mais il est inutile de faire un double contrôle préalablement dans le code.

Il y a eu un débat récemment (légèrement houleux par moments) sur la situation des contraintes en BDD ou dans le code.

Un avis mi figue mi raisin y avait été donné, suggérant de ne mettre en BDD que les contraintes fortes applicables quelle que soit l'application qui utilise la BDD Les contraintes d'intégrité référentielle en premier lieu, mais aussi les impossibilités logiques telles que le fait d'enregistrer une date de décès antérieure à une date de naissance.

Les contraintes propres à l'application seraient plutôt à mettre dans le code de l'appli car ce sont davantage des contraintes fonctionnelles. Par exemple le fait qu'une mise à jour de quantité soit impossible si la quantité est inférieure à un certain seuil, comme cela pourrait se rencontrer dans une gestion de stock.

En gros il faut distinguer les contraintes propre à la nature même de la donnée de celles dépendant de l'utilisation qui est faite de la donnée.

Un CHECK entre 0 et 10 est peut-être dans cette seconde catégorie ?

Après si la BDD n'est destinée à être utilisée que par une seule application, on peut tout mettre en BDD.

[passie]

Merci pour la réponse,
dans mon cas ce sont surtout des contraintes logiques du type la largeur de l'objet doit être comprise entre 0 et 200, du coup je pense plutôt aux contraintes déclarées côté SQL
mais aussi la seule contrainte NULL ou NOT NULL, c'est bien une contrainte mise aprés une décision des utlisateurs du coup puis je vérifier pour un champ si il est prévu NULL ou NOT NULL en SQL ?
ou alors faut il envoyer la requête d'insertion pour tout un enregistrement, attendre le résultat et traiter un éventuel message d'erreur qui ne sera pas forcement explicite.
Ma première idée est de le faire champ par champ, du style je récupére la saisie d'un seul et je teste si il "rentrerai" dans la table (je ne parle ici que des contraintes sur le type du champ et sur des plages de valeurs par expl).
Mais c'est juste une idée je ne sais pas encore comment le faire.
J'imagine une fonction plpgsql à qui l'on donne par expl la table, le champ et sa valeur saisie par l'utilisateur qui permettrai de tester si il peut être accepter ou pas !
Bon champ par champ c'est peut être un peu lourding mais pas plus que de le faire deux fois.

[CinePhil]

dans mon cas ce sont surtout des contraintes logiques du type la largeur de l'objet doit être comprise entre 0 et 200, du coup je pense plutôt aux contraintes déclarées côté SQL

Moi je dirais plutôt une contrainte fonctionnelle !
Qui dit que dans l'avenir la largeur ne pourra pas être supérieure à 200 ?
Enfin il faudrait des précisions sur le contexte pour en juger plus profondément.

mais aussi la seule contrainte NULL ou NOT NULL, c'est bien une contrainte mise aprés une décision des utlisateurs du coup puis je vérifier pour un champ si il est prévu NULL ou NOT NULL en SQL ?

Ca c'est plus une contrainte de modélisation de données !
Une clé primaire est systématiquement NOT NULL par exemple.
De même que peut l'être une clé alternative telle que le login utilisateur : sans login, l'utilisateur ne peut pas exister.
Par contre on peut ne pas connaître une information sur l'utilisateur, telle que sa date de naissance, et autoriser ainsi la colonne date_naissance a être NULL.

Les contraintes figurent dans les métadonnées de la BDD, lesquelles sont dans le schema information_schema. Parcours ses vues et tu y trouveras tes contraintes. Tu pourras ainsi en déduire les requêtes qui te permettront de les extraire.

ou alors faut il envoyer la requête d'insertion pour tout un enregistrement, attendre le résultat et traiter un éventuel message d'erreur qui ne sera pas forcement explicite.

C'est généralement comme ça qu'on fait et c'est au logiciel de présenter un message explicite ou de réagir de la manière appropriée au message.
Le SGBD va seulement dire, avec sa propre syntaxe, que telle contrainte n'a pas été respectée. Tu peux récupérer le code et le texte en clair de l'erreur.
Je n'en suis pas sûr mais je crois que tu peux spécifier un texte explicite avec les contraintes CHECK. A vérifier.

Pour ce qui est des contraintes NOT NULL, la meilleure méthode est de définir une valeur par défaut correspondant au type de la colonne. Il y en a une standard pour chaque type mais tu peux définir les tiennes, par exemple DEFAULT CURRENT_TIMESTAMP sur une colonne de type TIMESTAMP ou DEFAULT TRUE sur une colonne booléenne...

Ma première idée est de le faire champ par champ, du style je récupére la saisie d'un seul et je teste si il "rentrerai" dans la table (je ne parle ici que des contraintes sur le type du champ et sur des plages de valeurs par expl).
Mais c'est juste une idée je ne sais pas encore comment le faire.
J'imagine une fonction plpgsql à qui l'on donne par expl la table, le champ et sa valeur saisie par l'utilisateur qui permettrai de tester si il peut être accepter ou pas !
Bon champ par champ c'est peut être un peu lourding mais pas plus que de le faire deux fois.

Si tu essaies de faire un truc de ce style dans le logiciel, ça fera deux envois de requêtes au serveur, donc deux fois plus de temps. Mauvaise idée !

Il faut se dire que 95% des requêtes passeront sans douleur et que les messages d'erreur ne sont là que pour traiter les cas d'erreurs de saisie la plupart du temps et que ces cas doivent être rares, à moins que les utilisateurs tapent sur le clavier avec des moufles !

Les tests qui sont à mettre dans le logiciel sont :
- la présence de données dans les champs obligatoires des formulaires ;
- la cohérence de certaines saisies (mot de passe et sa répétition lors d'une inscription à un site par exemple)
- le traitement des cas d'erreur retrounés par le SGBD.

[estofilo]

On peut trouver quelles sont les contraintes CHECK sur les colonnes via la table information_schema.constraint_column_usage et en obtenir les clauses testées via la table information_schema.check_constraints.

Techniquement il est possible de générer une requête qui fasse que le SGBD va calculer chaque clause et produire un champ à true ou false pour chacune. Par exemple si on a une clause col>=1 and col<=10 et col2 is not null et les valeurs 12 et 'abc' à insérer, il faudrait générer et lancer:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

SELECT col>=1 AND col<=10, col2 is not null FROM (values(12,'abc')) AS s(col,col2)

Dans le résultat de cette requête, un champ à la valeur false indique que la contrainte correspondante serait violée si on insérait la donnée.

[passie]

Déjà merci pour vos réponses

Moi je dirais plutôt une contrainte fonctionnelle !

c'est juste

Qui dit que dans l'avenir la largeur ne pourra pas être supérieure à 200 ?

C'est justement ce que je me dit, mais ce que je pense c'est qu'en cas de changement de cette plage, il se fera d'abord côté SQL et qu'il faut aussi le faire dans le code de l'appli cliente si on veut garder une corrélation entre les deux, ou alors on tente de traiter le message d'erreur mais c'est peut être moins simple pour spécifier à l'utilisateur que la valeur doit être comprise entre 0 et 210 avant la saisie.

Je n'en suis pas sûr mais je crois que tu peux spécifier un texte explicite avec les contraintes CHECK. A vérifier.

Ca c'est une vraie piste intéressante faut creuser mais je pense que cela peut être la bonne solution pour avoir des retours d'erreur utilisables.

Le but principal étant bien de pouvoir assister l'utilisateur lors du remplissage en lui donnant si possible ce qu'on attend de lui sur chacun des champ de formulaire. Cela n'empêche pas de faire un retour explicite des messages d'erreurs éventuels mais en amont j'aimerai lui dire ce champ doit être par expl :

1. NOT NULL
2. De type integer
3. Compris en tre 0 et 220

Et c'est dans ce cas que je trouve dommage d'avoir à stocker les contraintes côté application alors qu'elles sont définies en SQL et qu'un changement quelconque se ferait d'abord en SQL.

Les tests qui sont à mettre dans le logiciel sont :
- la présence de données dans les champs obligatoires des formulaires ;

voila mais pour moi un champ obligatoire l'est parce qu'il reçoit une contrainte NOT NULL en SQL.

Bon c'est sur que c'est aussi de la fainéantise d'avoir à faire l'effort de bien synchroniser le formulaire avec la table dans le temps mais bon

Envoyé par estofilo
On peut trouver quelles sont les contraintes CHECK sur les colonnes via la table information_schema.constraint_column_usage et en obtenir les clauses testées via la table information_schema.check_constraints.

Techniquement il est possible de générer une requête qui fasse que le SGBD va calculer chaque clause et produire un champ à true ou false pour chacune

Voila c'est l'idée mais c'est vrai que c'est peut être lourd à faire et gourmand en ressources suivant le nombre de vérif à faire.

Reste la possibilité d'utiliser une table descriptive qui contient les infos sur chaque champ (un genre de dico de données) et s'en servir pour faire l'info utilisateur (au survol du libéllé du champ de formulaire par expl) et d'utiliser les valeurs de cette table pour faire l'affichage du formulaire (mettre en rouge avec une étoile si NOT NULL) et les vérifs (connaitre min / max etc...).
Mais le PB reste le même il faut s'assurer de la cohérence entre les containtes réelles (SQL) et celles décrites dans cette table, mais au moins on a toutes les infos dans une même table, c'est plus simple à maintenir.

Merci