Bonjour,

J'espère que je suis dans le bon forum car il s'agit bien de MySQL mais pas vraiment d'un problème de requête, plutôt sur "comment organiser".

Je m'explique : J'ai un formulaire de gestion de membres, et je souhaite que les utilisateurs ayant les droits puissent créer des champs supplémentaires de données, qui peuvent être très variés: texte libre, liste déroulante/bouton radio, checkbox et chargement de fichier.

Je ne sais pas trop comment faire pour gérer ça au niveau de ma BDD.
J'en ai vu certains qui ajoutaient directement des champs dans la table des membres mais ça me paraît dangereux en cas de mise à jour par exemple.
Je pense qu'il faut mieux le faire dans un table à part ?

Second point, la gestion des types de champs.
Faut-il mieux que je crée les champs dans cette table à part avec un alter table pour chaque nouveau champ, avec pour les listes déroulantes/checkbox/radio les choix possible dans un champ JSon, tandis que le chargement de fichier sera lui un blob ?

Bref, j'espère que ma demande est suffisamment claire pour que vous puissiez m'éclairer sur ce que je souhaite faire, et confirmer/infirmer ce que j'expose.

Merci !

Bonjour,

jouvrard a écrit:

je souhaite que les utilisateurs ayant les droits puissent créer des champs supplémentaires de données, qui peuvent être très variés: texte libre, liste déroulante/bouton radio, checkbox et chargement de fichier.

Tu es très gourmand en voulant tous ces types de données ...

Pour texte libre, checkbox et fichier, un champ texte serait suffisant. Pour select et radio, c'est autre chose ...

Je peux te proposer de créer deux tables de plus : membre_meta, et type_meta.

Ici le champ type_meta.options est un booléen (1 ou 0) précisant si le type a besoin d'une liste d'options ou non.

Dans la table membre_meta, tu associes un membre avec un type de meta, un libellé, une valeur, et une liste d'options (en JSON) le cas échéant.

Toute la logique de création et d'affichage sera par contre gérée côté application pour déterminer quoi afficher en fonction du type de métadonnées.

Tout d'abord merci pour ta réponse.

Je me pose la question pour le fichier. TEXT est limité à 65535 caractères si je ne me trompe pas, tandis qu'un blob ou mediumblob va beaucoup plus loin.
J'ai peur que TEXT ne soit pas suffisant du coup. Le but n'est pas de charger des fichiers énormes mais un fichier Word ou Excel peut rapidement être plus lourd que 65Ko.

jouvrard a écrit:

J'ai peur que TEXT ne soit pas suffisant du coup

Dans ma proposition, la méta-données ne contient que le chemin du fichier, pas le contenu ... Le fichier doit être téléchargé dans un répertoire sur le serveur, pas stocké en base. Je déconseille d'ailleurs de stocker les fichiers en base de données ... Ce n'est pas leur but, même si le type BLOB est fait pour, la gestion des fichiers devraient selon moi rester la prérogative du serveur de fichiers ...

Ne serait-ce que pour les temps de backup et de restore !

-
Edité par Benzouye 4 avril 2022 à 16:21:40

Ah excuse oui, j'avais dans l'idée que c'était vraiment pour le fichier en lui-même, autant pour moi.

Merci, je vais étudier tout ça.

je rouvre un peu le sujet juste pour un petit point : Pour toi, pour tout ce qui est stockage de petits fichiers (docx, xlsx et petits jpg), il faut toujours mieux le stocker dans un dossier sur le serveur plutôt que dans la BDD dans un champ blob ?

Le principal intérêt de la sauvegarde dans la BDD pour moi c'est pour la sauvegarde, où un simple mysqldump nous permet de tout sauvegarder, sans avoir à se soucier de tel ou tel dossier à prendre en plus.
Mais comme tu dis, ça fait grossir la BDD et augmente le temps de sauvegarde/restauration.

jouvrard a écrit:

Pour toi, pour tout ce qui est stockage de petits fichiers (docx, xlsx et petits jpg), il faut toujours mieux le stocker dans un dossier sur le serveur plutôt que dans la BDD dans un champ blob ?

Oui, petits ou gros fichiers d'ailleurs ... Cela fait exploser l'espace disque de la base et ralenti considérablement les dumps et restore éventuels. Cela implique aussi un décodage de données binaires côté application, qui peut être parfois un peu "tricky" ...

Mais c'est un avis personnel, tu trouveras de nombreuses personnes qui te donneront des avantages à stocker en base les données binaires des fichiers joints, notamment la liaison forte avec la donnée binaire : en stockant en base tu n'as pas à te soucier du serveur de fichiers et de la suppression/mise à jour du fichier physique décorélées de la base de données, qui est possible puisque le fichier physique n'est pas géré par la base ... Un petit malin supprime un fichier manuellement (FTP ou autre) ou le renomme, et l'intégrité est rompue ...