Bonjour,
J'aimerai faire un formulaire avec plusieurs checkbox à cocher qui décrivent des options et un input qui permet à l'utilisateur d'ajouter des options..
A votre avis, quelle est la meilleure structure pour la sauvegarde de ces options ? Mettre le tout dans un seul champ ou bien dénormaliser sur deux tables ou bien une autre solution ?
Merci :-)
Salut Beta :-)
Je cherche à proposer une liste d'options sous forme de checkbox où l'utilisateur pourra y greffer les siennes si jamais elles ne sont pas présentes.. maintenant, je cherche à sauvegarder le tout sur ma base. ( je sais pas si c'est assez clair :s )
Salut,
Pourrais-tu être plus précis ? Que cherches-tu à faire exactement ?
Salut,
Tu as réussi à implémenter ton système d'ajout l'input ? Ou tu demande de l'aide pour ça ?
Sinon pour la sauvegarde, tu peux mettre un champ de type hidden, récupérer les values des checkboxes checked dans un array, le "toString-er" et insérer la chaîne de caractères en value de ton input hidden, afin de récupérer les datas qui t'intéressent. Tu me suis ?
Non, non.. de ce coté-là, je gère.. je galère sur la structure de ma base de données ! Dois-je sauvegarder les choix en string brut ou bien faire une sorte de dénormalisation ?
Tu vas réutiliser les données dans quel but ? De l'affichage ou du traitement ? Et qu'appelles-tu "dénormalisation" ?
Eh bien, chaque article possède des "options" que l'utilisateur ( propriètaire ) lui assigne ! Et j'en ai besoin pour les deux, l'affichage et le traitement.
Je veux dire par là : créer deux tables, l'une contient sur chaque ligne une option alors que l'autre table contient un champ qui liste tout les id ! Bref, ça gagne du volume mais je trouve que c'est pas dévastateur en matière de temps et de requètes lors de l'affichage !
La question est: est-ce que l'utilisateur créée beaucoup de champs perso ou non ? Car ce que tu peux faire, c'est simplement rajouter à ta table un champ qui contiendra un JSON (stringifié cela va de soi) avec les infos sur les champs custom. Tu vois ce que je veux dire ? De cette manière tu évite la création d'une table dédiée, et ça te permettra de n'avoir qu'à faire un coup de json_decode() pour avoir accès aux infos.
Genre une seule table avec un champ qui contient "option1, option2,.... etc" ?
En faisant ça, tu perds la possibilité de pouvoir traîter les valeurs personnalisées d'un utilisateur depuis une requête SQL. De plus, il n'est pas considéré comme une bonne pratique d'utiliser des attributs multi-valués (cf. Première forme normale ).
Je te conseillerai plutôt de créer une table custom_options, avec des champs user_id, form_id, name, value. Tu peux faire tout ce que tu veux avec ces valeurs, et ça sera bien plus simple que d'avoir à les passer dans une moulinette à chaquette select / update / insert.
Oui voilà, mais ce qui m'attriste c'est que j'en ai au minimum une trentaine.. et niveau requête, c'est un peu lourd.. sauf si je me gourre :s
Beh non c'est juste le traitement qui sera un poil plus long. Tu as beaucoup d'utilisateurs en simultané ? Tu as peur que ton serveur de supporte pas la charge ?
Une trentaine de lignes (pas de tables ni de colonnes hein, tu as compris le rôle des champs name et value ?), c'est rien du tout :-) Mesure le temps que te prennent les différentes façons de faire, regarde les quelques ms d'écart, et rend-toi compte qu'en stockant du JSON, tu passeras plus de temps à devoir json_decode(), trier ou appliquer des opérations des champs, … alors que ce sont des opérations que tu aurais pu faire directement depuis une requête SQL.
Quand tu as peur que ça soit VÉRTIBLEMENT TROP LONG OMG, avant, teste, compare, regarde si tu exploites bien toutes les possibilités qui te sont offertes par le logiciel que tu utilises !
Peur pour le serveur, oui.. j'ai pas encore lancé le site ! M'enfin, merci à vous tous :-)
@flan +1
Merci pour ces bons conseils Flan.. je vais suivre la voie dénormalisée !