Stockage d'instructions en "commentaire" dans une table MySQL

[Papoupapa]

Bonjour,

Je consulte régulièrement ce forum car j'apprécie la qualité des discussions et le sérieux des contributions. Je trouve ici énormément de réponses à mes questions.

Il est possible d'ajouter un commentaire à une table MySQL et aux champs qui la composent. En ce qui me concerne, j'utilise ces zones de commentaires afin de stocker des codes que j'appelle ensuite dans un script afin de savoir quel traitement je dois appliquer à ce champ. Par exemple, dans la zone "comment" d'un champ où figure un identifiant correspondant à des données contenues dans une autre table, j'insère un code qui indique que ce champ doit être complété à partir d'une liste déroulante et j'ajoute le nom de la table cible où chercher les données, ainsi que les noms des champs où récupérer l'identifiant et la valeur dans la table cible. Cela me permet d'utiliser une petite application qui génère automatiquement des formulaires de saisie à partir des instructions contenues dans la zone commentaire.

Jusqu'à maintenant j'utilisais cette "fonctionnalité" uniquement en phase de recherche et développement et je m'interroge sur son emploi dans une application commerciale. Mes soucis concernent essentiellement la sécurité et j'aurais souhaité recueillir les avis d'utilisateurs qui utilisent de la sorte les zones de commentaires des table et champs MySQL.

Par avance, merci pour vos réponses !

Cordialement,
Papoupapa

[CinePhil]

Envoyé par Papoupapa

Par exemple, dans la zone "comment" d'un champ où figure un identifiant correspondant à des données contenues dans une autre table,

Ça s'appelle une clé étrangère et MySQL les gère du moment que la table utilise le moteur InnoDB.

j'insère un code qui indique que ce champ doit être complété à partir d'une liste déroulante et j'ajoute le nom de la table cible où chercher les données, ainsi que les noms des champs où récupérer l'identifiant et la valeur dans la table cible.

Pour ce cas, précis, il vaut mieux interroger information_schema.

Cela me permet d'utiliser une petite application qui génère automatiquement des formulaires de saisie à partir des instructions contenues dans la zone commentaire.

Pourquoi pas mais il vaut mieux interroger information_schema ou travailler avec des métadonnées.

Jusqu'à maintenant j'utilisais cette "fonctionnalité" uniquement en phase de recherche et développement et je m'interroge sur son emploi dans une application commerciale. Mes soucis concernent essentiellement la sécurité et j'aurais souhaité recueillir les avis d'utilisateurs qui utilisent de la sorte les zones de commentaires des table et champs MySQL.

Ça ne me serait jamais venu à l'idée d'utiliser la zone de commentaires pour ça. Elle n'est pas faite pour ça à mon avis.

En principe, on développe une application utilisant une BDD en connaissant le schéma de données et les contraintes qui y figurent. Le mieux est même de ne mettre à disposition du développeur que les vues métier dont il a besoin.

Au fait, les champs sont à la campagne ou dans les formulaires, pas dans les tables SQL.

[Papoupapa]

Merci CinePhil pour votre réponse.

Mon exemple était simple et il peut, c'est vrai, être traité au moyen d'une clé étrangère (table key_colum_usage).

La base information_schema contient en fait les caractéristiques des tables et colonnes (je laisse les champs à la campagne...), dont les commentaires que j'ajoute.

Je prends un autre exemple, toujours avec mon générateur automatique de formulaire. S'il s'agit de définir une "textarea", la zone commentaire inclut la taille de la zone de texte à inclure dans le formulaire (nombre de lignes et nombre de colonnes) pour chaque colonne. Si je me contente des données disponibles dans la table columns de information_schema, je n'ai accès qu'à la nature de la colonne et à la taille maximale de chaque valeur que peut contenir la colonne. Je peux définir une convention de dimensionnement en fonction de ces données mais ce n'est pas ce que je souhaite faire.

J'ai conscience que la bonne pratique consisterait à créer une table où seraient définies les règles (de dimensionnement mais également d'autres règles et instructions), mais je cherchais à avoir un retour d'expérience concernant cet emploi, dévoyé (?), de la colonne column_comment de la table columns dans la base information_schema.

Cordialement,
Papoupapa

[CinePhil]

Votre démarche est peut-être justifiable dans votre cas précis mais s'il s'agit de généraliser ce concept, ça me gène car une base de données est susceptible d'être utilisée par plusieurs logiciels. Vouloir stocker dans les commentaires de la table des contraintes applicatives revient à vouloir brider une voiture fabriquée en France à 130 km/h alors qu'elle peut être vendue et utilisée dans un autre pays avec une limitation de vitesse plus grande ou pas de limitations du tout !

La BDD ne doit à mon sens contenir que les informations et contraintes sur les données, indépendamment des applications qui vont l'utiliser.

Imaginons qu'une entreprise ait une base de données avec une table de personnes pour y enregistrer les informations sur ses salariés, dont la date de naissance. Comme on ne peut pas travailler avant 16 ans en France, on pourrait être tenté de mettre une contrainte sur la date de naissance afin d'interdire la saisie, par erreur, d'une date de naissance inférieure à aujourd'hui - 16 ans.
Puis plus tard, cette table est aussi utilisée pour enregistrer les enfants du personnel et la contrainte préalablement mise n'est plus valable.

C'est peut-être un exemple un peu bête mais pour moi, les contraitnes applicatives doivent figurer dans les applications et les contraintes inamovibles sur les données doivent figurer dans la BDD.

Pour reprendre votre exemple, vous pouvez décider aujourd'hui que toute colonne de type TEXT sera alimentée à partir d'une TEXTAREA de 5 lignes de 80 caractères. Demain vous aurez un écran de saisie avec relativement peu d'informations mais une TEXTAREA destinée à recevoir un texte en moyenne de 1000 caractères. Vous aurez alors peut-être envie de voir tout le texte saisi sur votre écran, puisque vous avez la place. Mais si le formulaire est créé dynamiquement à partir des données lues en BDD, ce ne sera pas possible.

Bref, je ne suis vraiment pas convaincu par la démarche, désolé !

[Papoupapa]

En effet je comprends l’intérêt de distinguer le stockage des données des instructions concernant leur manipulation; c'est un paramètre dont il a été tenu compte dans l'élaboration du cahier des charges.
Merci pour votre contribution.

Cordialement,
Papoupapa