Discussion :

[dafpp]

bonjour,
j'en ai l'habitude, simple question:
Est-il plus intelligent de mettre un maximum de contraintes dans sa BDD, que ce soit vertical ou horizontal (CHECK, UNIQUE, ...), et prendre le risque que ça plante si on insère qqchose; que de faire les vérif dans la page php, et devoir de temps en temps vérifier la BDD pour être sûr de ne pas mettre quelque chose qui ne respecte pas la règle ?

Je pense qu'en posant ma question je me réponds moi même, mais j'aimerai avoir des avis. Est ce que des contraintes (un maximum), permet ainsi une (quasi) totale aisance dans sa page php, et permettre de ne vérifier que la variable d'erreur de BDD s'il y a eu une erreur ? Je pense que vérifier au moins la taille des chaînes des caractères, ou la taille des données a rentré sont un minimum à vérifier.

Merci d'avance

edit: j'ai pu lire ça

La contrainte CHECK de validation est celle qui offre le plus de possibilité. En contre partie son exécution est très coûteuse. Elle permet de définir un prédicat complexe, basé sur une comparaison pouvant contenir une requête de type SELECT. Pour valider la contrainte, le prédicat doit être évalué à TRUE ou UNKNOWN (présence de NULL).

cela en vaut vraiment la peine, si on recherche de la vitesse d'execution ?

[CinePhil]

Tu peux lire ce que dit Frédéric Brouard, alias SQLPro chez Developpez.com, sur le concept de base de données épaisse.

À mon avis, il faut distinguer la solidité des données, dont le contrôle revient au SGBD, des spécificités d'une application qui utilise la BDD.

Par exemple, je pourrais avoir dans une entreprise une base de données de gestion de documents avec le titre du document dans une colonne de type VARCHAR(255). Si les besoins d'une application qui utilise cette BDD déterminent que le titre des documents qu'elle génrère ne doit pas dépasser 50 caractères, alors c'est peut-être mieux que ce soit l'application qui contrôle cette contrainte. Mais on pourrait aussi programmer une contrainte en BDD pour que les documents de type X - ceux qui sont générés par cette application - aient un titre inférieur à 51 caractères.

En mettant les contraintes dans la BDD, cela demande au développeur de l'application de gérer les erreurs retournées pas le SGBD relatif à ces contraintes.

Et au passage, CHECK est inconnu de MySQL ; c'est une de ses grosses lacunes par rapport à la norme SQL.

[SQLpro]

bonjour,
j'en ai l'habitude, simple question:
Est-il plus intelligent de mettre un maximum de contraintes dans sa BDD, que ce soit vertical ou horizontal (CHECK, UNIQUE, ...), et prendre le risque que ça plante si on insère qqchose; que de faire les vérif dans la page php, et devoir de temps en temps vérifier la BDD pour être sûr de ne pas mettre quelque chose qui ne respecte pas la règle ?

Il n'y a aucune équivalence entre les contraintes d'un SGBDR et le code applicatif.
Un code applicatif ne peut en aucun cas réaliser l’équivalent de :

• clef primaire
• contrainte d'unicité
• contraintes FOREIGN KEY

du fait de la nature ensembliste et transactionnelle des opérations du SGBDR que ne peut reproduire aucun code itératif d'aucune sorte, PHP comris (surtout PHP !)
En ce qui concerne la contrainte CHECK. Si elle porte sur une ligne, on peut la simuler dans un code client. Maintenant si elle porte sur la table entière ou vérifie d'autres tables c'est strictement impossible.

Je pense qu'en posant ma question je me réponds moi même, mais j'aimerai avoir des avis. Est ce que des contraintes (un maximum), permet ainsi une (quasi) totale aisance dans sa page php, et permettre de ne vérifier que la variable d'erreur de BDD s'il y a eu une erreur ? Je pense que vérifier au moins la taille des chaînes des caractères, ou la taille des données a rentré sont un minimum à vérifier.

Merci d'avance

edit: j'ai pu lire ça

cela en vaut vraiment la peine, si on recherche de la vitesse d'execution ?

Dire que la contrainte CHECK est couteuses est vrai dans certains cas, mais bien moins que ce que vous feriez avec un code qui n'est pas spécialisé dans les données. De plus le tsmps étant "dilué" dans les INSERT/UPDATE, vous aurez de réelle difficultés à le montrer comme à vous en rendre compte !

Ceci dit, vu la pauvreté de MySQL (à lire : MySQL un SGBDR poudre aux yeux) vous aurez du mal à implémenter des contraintes intelligente !

A lire sur les contraintes : http://sqlpro.developpez.com/contrai...aintes_SQL.pdf

Quand à vérifier la taille des chaines saisies, vous pouvez le faire en limitant directement le nombre de caractères dans le champ de l'IHM !

A +

[dafpp]

D'accord, c'est juste que j'utilise MySQL par défaut, c'est celui qui nous ai demandé d'utilisé en cours (oui j'ai vu pas mal de critique dessus) .
Mais dans ce cas là, quel est pour vous le meilleur SGBD ? (sans doute déjà parlé, donc juste un lien ne me dérangera pas)

CHECK n'est utile que lors de l'insertion, mais si je n'ai mis aucune contrainte et que je tente d'ajouter une donnée qui ne rentre pas dans les règles imposés lors de la création de la table, il y aura automatiquement refus d'enregistrer cette dernière, et donc la ligne ne sera pas rempli (NULL) là où il y aura eu non respect du type ?

[dafpp]

je me demandais aussi, pourquoi on voit toujours en SGBD dans les livres MySQL (j'ai lu la liste des gros défauts de MySQL), pourquoi s'il est si mauvais, pourquoi est ce quelque chose qu'on enseigne souvent (à mon DUT c'est MySQL et Oracle, qui est considéré les 2 moins bon SGBD) en cours dans les livres ou à l'université ?
autre chose, je suis sous OVH, est-ce qu'il font exclusivement du MySQL, ou il y a possibilité d'utiliser autre chose ?

[CinePhil]

D'accord, c'est juste que j'utilise MySQL par défaut, c'est celui qui nous ai demandé d'utilisé en cours (oui j'ai vu pas mal de critique dessus) .
Mais dans ce cas là, quel est pour vous le meilleur SGBD ? (sans doute déjà parlé, donc juste un lien ne me dérangera pas)

Si tu veux rester dans le libre, tu as Postgresql qui est plus rigoureux que MySQL. Pour tes besoins personnels à des fins d'études, tu as aussi MS SQL Server Express sous Windows.

CHECK n'est utile que lors de l'insertion, mais si je n'ai mis aucune contrainte et que je tente d'ajouter une donnée qui ne rentre pas dans les règles imposés lors de la création de la table, il y aura automatiquement refus d'enregistrer cette dernière, et donc la ligne ne sera pas rempli (NULL) là où il y aura eu non respect du type ?

Ça dépend de la donnée et/ou de son type et/ou du SGBD. Je crois que chez MySQL, si tu essaie d'insérer un texte dépassant la capacité d'une colonnes VARCHAR, le texte est tronqué. Une mauvaise date entraînera la fausse date que MySQL considère comme NULL : '0000-00-00'.

[dafpp]

Ça dépend de la donnée et/ou de son type et/ou du SGBD. Je crois que chez MySQL, si tu essaie d'insérer un texte dépassant la capacité d'une colonnes VARCHAR, le texte est tronqué. Une mauvaise date entraînera la fausse date que MySQL considère comme NULL : '0000-00-00'.

Mais j'aurai au moins un retour de valeur dans mysql_errno ?

Je vais sans doute me rediriger vers un autre SGBD, donc j'aimerai savoir quel serait le meilleur pour un site web, où la vitesse d’exécution des requêtes et du retour des résultats sera très important.
La BDD ne sera pas énorme, mais elle faudrait qu'elle soit le plus rapide possible.

Par exemple: qu'est ce qu'utilise developpez.com ?

[CinePhil]

Je vais sans doute me rediriger vers un autre SGBD, donc j'aimerai savoir quel serait le meilleur pour un site web, où la vitesse d’exécution des requêtes et du retour des résultats sera très important.
La BDD ne sera pas énorme, mais elle faudrait qu'elle soit le plus rapide possible.

Si tu n'as pas de contrainte de la part de ton hébergeur, tu peux choisir Postgresql si tu veux un produit plus rigoureux que MySQL.

Par exemple: qu'est ce qu'utilise developpez.com ?

Vu le volume de données et le nombre d'utilisateurs simultannés du site, quelque chose me dit que c'est probablement un SGBD costaud qui assure le service des données, genre Oracle ou MS SQL Server ou DB2.