Structure d'une base de données de sondage

Salut à tous!
Voilà, ma question repose sur la structure d'une BDD que je dois concevoir. Cette BDD doit contenir les informations de sondages.

Les tables de la base sont:

• 1 table pour les utilisateurs, où chaque entrée est un utilisateur
• x tables pour les x sondages (tous les sondages n'ont pas forcément les mêmes possibilités de réponses, d'où le besoin de faire une table par sondage), où chaque entrée est une réponse à un sondage
• 1 table d'index avec x entrées, où chaque entrée est un sondage et ses caractéristiques
• 1 table de réponses, où chaque entrée est une réponse, contenant le numéro de l'utilisateur, le numéro du sondage (table?) et le numéro de la réponse interne au sondage. Cette table vise à sécuriser les réponses

Ma question repose donc sur la faisabilité du 2ème champ de la 4ème catégorie de table, à savoir, un champs contenant l'id d'une table. Est-ce possible?

Bonjour Nihilivin,

Pour ma part je n'ai pas la réponse à ta question, tel que posée.
Je vais me tourner vers une proposition pour toi :

- Une table utilisateur (id, nom, prénom, etc...)
- Une table sondage (id, nom, description/question, etc...)
- Une table réponses possible (id, id_sondage, nom/réponse, etc...)
- Une table réponses utilisateurs (id, id_utilisateur, id_sondage, id_reponse)

Pour limiter les réponses, voir "UNIQUE" sur le couple de champs id_utilisateur/id_sondage de la table réponse utilisateur

Après ce n'est qu'une suggestion, et je peux comprendre que ce soit pénible de recommencer si tu as déjà avancé suivant ton point de vue ^^.

Bonjour, et merci pour votre réponse,

Le problème de cette méthode, c'est que cela nécessite donc que tous les sondages aient le même type de réponses (contrainte de type de champs), enfin je crois... Ou que les différents types soient présents, mais tous "void", sauf celui demandé, mais dans ce cas, cela implique d'avoir une unique question dans un sondage.

Or, un sondage, dans ma définition, est un groupe de questions dont les réponses ne sont PAS FORCEMENT du même type (int, bool, string, bytearray, que sais-je). Une situation possible est qu'un sondage doive stocker, par exemple, 5 booléens et un Int, et un autre stocke 1 boléen et du texte, et je ne veux pas étendre ma table des sondages à chaque fois qu'une nouvelle combinaison de réponses est ajoutée...

Je ne sais pas si c'est très clair... Mais mes contraintes sont là. Si on fait un rapprochement avec de la POO, on pourrait dire que chaque réponse est une instance d'un objet DIFFERENT pour chaque sondage, car ses attributs (groupe de réponses d'un seul utilisateur pour un seul sondage) seront de nature différente pour chaque sondage.
En continuant le parallèle avec la POO, la solution serait que chaque sondage soit un objet héritant d'un sondage "générique", et de créer une liste d'objets du sondage générique, pouvant ainsi stocker tous les objets héritant de la classe mère... :weird:

Bonsoir,

Pour obtenir une BDD bien structurée, il convient de passer par :
- la phase de conception, en réalisant un schéma ad hoc (MCD, Diagramme de classe UML, ...)
- la phase logique en réalisant un schéma relationnel sur les données (un MLD par exemple)
- la phase physique, où vous pourrez créer vos tables concrètement

Parallèlement, pour un projet d'une certaine envergure, il faut étudier également les traitements (programmes, requêtes SQL, ...) qui seront exécutés, avec UML par exemple. Ce sont les traitements qui nous guident pour organiser les données.

Vous trouverez des forums dédiés à ces pratiques sur developpez.com

Lorsque l'on créé directement une BDD sans passer par les phases appropriées, on obtient un résutat non professionnel qui fini généralement dans une poubelle :mouarf:

Un projet doit être conçu avant d'être réalisé.

Merci pour ces indications.

Effectivement, j'ai déjà fait de la conception logicielle, mais jamais de BDD... Donc... Je suis entièrement à l'écoute sur toutes les bonnes pratiques à avoir pour faire une base de qualité. Je vais me renseigner dès demain sur les 3 phases que tu as indiquées. Je vous tiendrai au courant de mes avancées, si vous y voyez des améliorations, je suis prenneur

Citation:

---

Envoyé par Nihilivin

Salut à tous!
Voilà, ma question repose sur la structure d'une BDD que je dois concevoir. Cette BDD doit contenir les informations de sondages.

Les tables de la base sont:

• 1 table pour les utilisateurs, où chaque entrée est un utilisateur
• x tables pour les x sondages (tous les sondages n'ont pas forcément les mêmes possibilités de réponses, d'où le besoin de faire une table par sondage), où chaque entrée est une réponse à un sondage
• 1 table d'indexes avec x entrées, où chaque entrée est un sondage et ses caractéristiques
• 1 table de réponses, où chaque entrée est une réponse, contenant le numéro de l'utilisateur, le numéro du sondage (table?) et le numéro de la réponse interne au sondage. Cette table vise à sécuriser les réponses

Ma question repose donc sur la faisabilité du 2ème champs de la 4ème catégorie de table, à savoir, un champs contenant l'id d'une table. Est-ce possible?

---

.

En générale quand on touche au BDD, vous devriez dessiner manuellement vos tables. En utilisant la méthode MERISE ou UML, chaque table( entité) doit contenir des champs (attributs). L'identificateur de la table, c'est que l'on appelle clé primaire. En générale, une table doit avoir une seul clé primaire et éviter de mettre la dedans la possibilité de faire des doublons.
pas forcement que l'on nomme id le clé primaire. Car tous les champs peuvent être choisis si l'on met "sans doublons". Mais la question de réalisation: *"quel logiciel, vous avez utilisé pour votre projet? Car la réponse aussi varie par rapport au logiciel que vous utiliserez":P

Je tiens à ajouter à tout ce qui a été dit que :
- "c'est que cela nécessite donc que tous les sondages aient le même type de réponses"

Pas forcement, je pense qu'il vaut mieux trouver une autre solution que de définir le type de ces champs de table suivant les réponses possibles, cela alourdi la conception à mon sens.

Et pour rinhary, il dit vrai, la clé primaire n'a pas forcement de nom propre à elle, cela peut être n'importe quel champ. Ceci dit, pour ma part, je préfère garder comme nom "id" ou encore "id_[nom de la table]", ça me permet de structurer rapidement mes tables pour les prochains lecteurs ^^. D'autant plus qu'avec "auto_incrément", je n'ai donc pas à m'en soucier (car unique obligatoirement, donc c'est le champs idéal pour devenir la clef primaire)

Bonjour,

Concernant le concept de clé primaire, il y a beaucoup à dire, mais je vais faire très court.

Chaque table possède une clé primaire si vous souhaitez travailler dans un contexte "SQL". Mais n'oublions pas que dans la Théorie Relationnelle de Ted Codd (l'inventeur génial du monde "relationnel") le concept de clé primaire est aujourd'hui obsolète (plusieurs clés candidates peuvent être définies).

Pour choisir une bonne clé primaire dans le contexte SQL, qu'elle soit définie sur une ou plusieurs colonnes, celle-ci doit effectivement être unique, mais ce n'est pas suffisant. Depuis 1970, l'expérience a démontré qu'elle doit également être non significative et invariante.


PS : Je profite de ce post pour rectifier le jargon utilisé :
- Les champs sont à la campagne, dans une table SQL on parle de colonnes.
- Le terme attribut vient de la Théorie Relationnelle. Avec SQL on parle de colonnes.
J'ajoute que si vous parlez de conception, dans ce cas on ne parle plus de table mais d'entité-type avec Merise, ou de classe avec UML.

Citation:

---

Envoyé par MacFly58

PS : Je profite de ce post pour rectifier le jargon utilisé :
- Les champs sont à la campagne, dans une table SQL on parle de colonnes.
- Le terme attribut vient de la Théorie Relationnelle. Avec SQL on parle de colonnes.
J'ajoute que si vous parlez de conception, dans ce cas on ne parle plus de table mais d'entité-type avec Merise, ou de classe avec UML.

---

Oulàà, j'avoue ne pas être attaché aux bons termes ^^, ceci dit, j'avoue aussi ne pas être le bon exemple, merci pour cette piqûre de rappel, j'avais totalement oublié ces termes depuis ma formation :).

J'avoue être un peu largué...

Les tables des sondages seront générées automatiquement via un programme externe à chaque nouvelle édition de sondage. A priori, aucune opération humaine ne sera nécessaire à la modification de la base de données. J'ai expliqué ma logique à des amis, et ils m'ont effectivement dit que cela sort du domaine de la base de donnée relationnelle. Les adresses de tables ne sont plus "statiques", mais "logiques", indexées dans une autre table tel que je l'avais dit plus haut. J'ai donc des avis pour, et des avis contre....

Nihilivin,

Je n'ai peut être pas bien compris les restrictions liées au projet, je vais vous présenter un peu mieux mon point de vue dans un premier temps pour vous laisser juger, après ça vous pourrez donc me dire ce qui vous embête.

Donc pour ma part je verrais plus quelque chose du genre :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49

tab_utilisateurs |----------------------------------------------| | id_utilisateurs | nom | prenom | etc...| |----------------------------------------------| | 1 | huzima | xxx | ... | |----------------------------------------------| | 2 | Nihilivin | xxx | ... | |----------------------------------------------| tab_sondages |----------------------------------------------------------------------------------------| | id_sondages | nom | question | type | |----------------------------------------------------------------------------------------| | 1 | Voiture préférées | Quel est votre marque de voiture préféré | unique | |----------------------------------------------------------------------------------------| | 2 | fruit mangés | Quels fruits aimez vous manger en dessert | multiple | |----------------------------------------------------------------------------------------| tab_reponses |---------------------------------------| | id_reponses | id_sondage | reponse | |---------------------------------------| | 1 | 1 | Alfa Romeo | |---------------------------------------| | 2 | 1 | Audi | |---------------------------------------| | 3 | 1 | Bentley | |---------------------------------------| | 4 | 2 | Pomme | |---------------------------------------| | 5 | 2 | Poire | |---------------------------------------| | 6 | 2 | Banane | |---------------------------------------| | 7 | 2 | Peche | |---------------------------------------| tab_resultats |----------------------------------------------| | id_resultats | id_utilisateurs | id_reponses | |----------------------------------------------| | 1 | 1 | 2 | |----------------------------------------------| | 2 | 2 | 3 | |----------------------------------------------| | 3 | 1 | 6 | |----------------------------------------------| | 3 | 1 | 7 | |----------------------------------------------|

---

Dans cet exemple;
- À la question "Quel est votre marque de voiture préférée ?" une seule réponse est possible par utilisateur car défini par le champ "Type" de la table "tab_sondage" (la vérification des réponses déjà données et donc à faire par le code), l'utilisateur "huzima" aurait répondu "Audi" alors que l'utilisateur "Nihilivin" préférerait plutôt "Bentley".

- À la question "Quels fruits aimez-vous manger en dessert ?" plusieurs réponses sont possibles par utilisateur car, toujours défini par le champ "Type" de la table "tab_sondage" (ici, pas besoin de vérifier si l'utilisateur a déjà ou non répondu), l'utilisateur "huzima" aurait répondu "banane" et "pêche" alors que l'utilisateur "Nihilivin" n'aurait pas encore donné de réponse.

-----------------------------------------------------------------

Quand vous dites que les réponses ont des types différents, par cette méthode le type importe peu, le nombre est illimité par sondage et c'est un sondage qui peut permettre des checkbox comme des bouton radio (je ne vois pas trop d'autre type de sondage), de plus, excepté évidement lors de la création d'un sondage qui se ferait par un formulaire, on ne touche pas à la base de données :

Pour la création il faut :
- Textbox : Nom du sondage
- Textbox : Question du sondage
- combobox : type du sondage (Réponse unique/multiple)

Module de réponse (Ajouter une réponse)
- Textbox : Réponse (ajout infini)

Les résultats se retrouveraient de cette façon :
Cela permettrait d'obtenir les résultats pour le sondage sur les marques de voiture

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

SELECT count(`tab_resultats`.`id_resultat`), `tab_reponses`.`reponse` FROM `tab_resultats`, `tab_reponses`, `tab_sondage` WHERE `tab_reponses`.`id_reponses` = `tab_sondages`.`id_sondages` AND `tab_reponses`.`id_reponses` = `tab_resultats`.`id_resultats` AND `tab_sondages`.`id_sondages` = '1' GROUP BY `tab_reponses`.`reponse`

---

N'est-ce pas ce que vous cherchez à faire ?

Ok... Et supposons maintenant que je veuille stocker un integer, ou, pire, un float... J'vais pas stocker 1 réponse possible par float possible! Ou des byte array... Sachant que cette BDD sera ammenée à avoir plusieurs milliers d'utilisateurs, plusieurs centaines de sondages et plusieurs centaines de milliers de réponse! (au moins 1000 réponses par sondage, mais ça peut monter beaucoup plus). Et ça va me faire stocker CHAQUE réponse possible à CHAQUE question (et non sondage, car un sondage est un ensemble de questions renvoyant chacune une réponse différente et pas forcément de même nature) de CHAQUE sondage?

Et, les énoncés des questions ne seront pas stockés dans la BDD. En tout cas pas à cet endroit. Ça, c'est autre chose, mais j'ai déjà entièrement mon idée. Inutile donc de penser aux énoncés des questions.

Et pourquoi pas ?

Les stats de visites de chaque sous forum de développez.net sont surement du même acabit, une table avec plusieurs millions d'enregistrement n'a rien d'extraordinaire :).

Sinon, si ça vous dérange tant que ça, il y a une solution de tableau dans la base, pas très propre à mon sens mais ça peux vous permettre de maintenir 1 enregistrement en base pour x question ou x réponse, il suffit d'utiliser "serialize" (en PHP) j'imagine qu'il doit y avoir des équivalent dans un peu tous les langages !

Mais croyez mois que vous ne devez pas vous en faire pour le nombre d'enregistrement, la gestion des données est assez bien optimisé !

En fait, il faudrait d'un expert du type "administrateur de base de données" de métier passe par ici pour vous en dire plus :).

Edit :
J'ai oublié de préciser que peu importe la méthode, un boolean reste un boolean, un integer reste un integer, et ce, peu importe la façon de le stocker, que ce soit dans une table ou dans une base de données, créer plusieurs centaine de base de données pour enregistrer plusieurs milliers d'enregistrement sur un serveur n'est clairement pas plus optimisé que d'enregistrer ces millions de données dans une seule et même table, la place prise restera la même en terme de volumétrie en revanche, la structure sera plus facile, autant pour l'humain, que pour la machine selon moi.

Le problème, c'est qu'il y aura également des champs libres ou l'utilisateur rentrera le texte qu'il veut, sur 255 caractères, par exemple. Vais-je devoir stocker 28^255 (et même plus pour les symboles) réponses? Oo