Discussion :

[redah75]

si alors je mets ca :

table reponses :
1 | 10224 | un peu

"un peu" se refere a quelle choix????

si je mets ca :

table reponses :
1 | 10224 | 101

ca veut dire que le participant 10224 a coche qlq chose pour le choix 101 mais on ne sais toujours pas si il a choisi "beaucoup", "un peu" ou "pas du tout"!!!

[Maljuna Kris]

Au temps pour moi, (j'ai du mal aujourd'hui).
J'avais zappé un niveau.
Donc, il faudrait 4 colonnes à la table réponse.

[redah75]

hehe et on revient sur ce que j'ai dit tout au debut

dans le cas où j'ai plusieurs reponses pour une
ou sinon je modifie la table enquetes_reponses :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

table enquetes_reponses (id_question, id_choix, reponse)

??

je rajoute le chmp en question ds la table reponses et te tiens ou courant de ce que ca donne
reponses {id_question, id_choix, id_participant, reponse}

[redah75]

2 petite choses:
ca serait pas mieux de mettre
reponses {id_choix, id_participant, reponse}
puis id_question je l'aurais par id_choix dans la table choix ??

pour les reponses, etant donne que je vais avoir bp de reponses du genre "pas du tout", serait il mieux de cereer une table speciale pour les reponses ???
reponses {id_choix, id_participant, id_reponse}
reponses_liste {id, reponse} // id: key, autoincrement

[Maljuna Kris]

ca serait pas mieux de mettre
reponses {id_choix, id_participant, reponse}
puis id_question je l'aurais par id_choix dans la table choix ??

Ça c'est parce que la table choix n'est pas en forme normale, son identifiant naturel devrait être la clef étrangère de la question combinée avec le rang du choix (1, 2, 3, ..., n)

pour les reponses, etant donne que je vais avoir bp de reponses du genre "pas du tout", serait il mieux de créer une table speciale pour les reponses ???
reponses {id_choix, id_participant, id_reponse}
reponses_liste {id, reponse} // id: key, autoincrement

pas compris

[redah75]

Ça c'est parce que la table choix n'est pas en forme normale, son identifiant naturel devrait être la clef étrangère de la question combinée avec le rang du choix (1, 2, 3, ..., n)

Qu'est ce que tu preconises alors???

pas compris

hehe je donne un exemple ca serait plus simple:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
reponses {id_choix, id_participant, reponse} :
101 | 10024 | un peu
102 | 10024 | un peu
105 | 10024 | beaucoup
107 | 10024 | un peu
108 | 10024 | beaucoup

serait il mieux de faire :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
reponses {id_choix, id_participant, id_reponse}
101 | 10024 | 1
102 | 10024 | 1
105 | 10024 | 2
107 | 10024 | 1
108 | 10024 | 2
 
reponses_liste {id, reponse}
1 | un peu
2 | beaucoup

??

et je ne sais meme pas encore comment gerer le cas d'une reponse "Autres" !!

[Maljuna Kris]

Qu'est ce que tu preconises alors???

De déclarer choix{id_question,id_choix, libelle} avec primary key combinée id_question, id_choix, id_question foreign key et id_choix auto_increment.
Normalement, MySQL recommence la sous-série des AUTO_INCREMENT à 1 pour chaque nouvelle valeur id_question associée.

reponses {id_choix, id_participant, id_reponse}

Non.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
reponses {id_question,id_choix, id_participant, id_reponse} 
avec id_reponse en ENUM('un peu','beaucoup','autres') NOT NULL DEFAULT 'autres'

par exemple

[redah75]

j'utilise phpmyadmin, c'est normal qu'il ne propose pas la possibilite de definir un champs comme clef etrangere??

Non.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
reponses {id_question,id_choix, id_participant, id_reponse} 
avec id_reponse en ENUM('un peu','beaucoup','autres') NOT NULL DEFAULT 'autres'

par exemple

je ne peux pas utiliser le type ENUM pour 2 raisons :
1- il peut y avoir d'aures reponses comme le montre la question 3 dans le formulaire (Comment souhaitez-vous pouvoir disposer de ces informations ?)

2- lorsqu'un participant choisi "Autres" il saisi sa reponse dans un champ de texte...

[Maljuna Kris]

j'utilise phpmyadmin, c'est normal qu'il ne propose pas la possibilite de definir un champs comme clef etrangere??

Oui.
MySQL ne gère les contraintes d'intégrité FOREIGN KEY que sur les tables de type InnoDB.
Tu dois impérativement lire ceci avant de te lancer là-dedans : http://dev.mysql.com/doc/refman/5.0/...nstraints.html

je ne peux pas utiliser le type ENUM pour 2 raisons :
1- il peut y avoir d'aures reponses comme le montre la question 3 dans le formulaire (Comment souhaitez-vous pouvoir disposer de ces informations ?)

2- lorsqu'un participant choisi "Autres" il saisi sa reponse dans un champ de texte...

Rien n'empêche de définir tout les cas de figure dans le type ENUM au moment de la création de la table, et de n'utiliser que les cas utiles pour chaque choix.
Le type ENUM permet d'affecter la valeur 0 à des valeurs autres que celles proposées en choix. (à lire aussi)
Tu pourrais pour ces cas là avoir une table en liaison 0,1 avec la table réponse {id_question,id_choix,id_participant,autre}, si, et seulement si, id_choix dans reponses est à 0.( à distinguer de NULL => pas de choix pour cette question).

[redah75]

Ohlalalalalaaaaaaa!!! je commence a m'arracher les cheveux
toutes mes tables sont en MyISAM, je vais lire ce que tu m'as envoye!!
quels sont les avantages et inconvenients de ces 2 types de bases mise a part la possibilite de mettre des cles etrangeres??? (rapidite, optimisation, ...)

pour vite en finir, je pense que je vais mettre cette solution pour les reponses :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
reponses {id_choix, id_participant, reponse} :
101 | 10024 | un peu
102 | 10024 | un peu
105 | 10024 | beaucoup
107 | 10024 | un peu
108 | 10024 | beaucoup

c'est pas grave s'il y a des repetitions!!!

[Maljuna Kris]

quels sont les avantages et inconvenients de ces 2 types de bases mise a part la possibilite de mettre des cles etrangeres??? (rapidite, optimisation, ...)

Je te dirais bien de lire cette page dont voici un extrait

Ventajas: MyISAM vs InnoDB
InnoDB

* Soporte de transacciones
* Bloqueo de registros
* Nos permite tener las características ACID (Atomicity, Consistency, Isolation and Durability: Atomicidad, Consistencia, Aislamiento y Durabilidad en español), garantizando la integridad de nuestras tablas.
* Es probable que si nuestra aplicación hace un uso elevado de INSERT y UPDATE notemos un aumento de rendimiento con respecto a MyISAM.

MyISAM

* Mayor velocidad en general a la hora de recuperar datos.
* Recomendable para aplicaciones en las que dominan las sentencias SELECT ante los INSERT / UPDATE.
* Ausencia de características de atomicidad ya que no tiene que hacer comprobaciones de la integridad referencial, ni bloquear las tablas para realizar las operaciones, esto nos lleva como los anteriores puntos a una mayor velocidad.

La elección es un tema delicado ya que hay que conseguir la mejor relación de calidad acorde con nuestra aplicación, obviamente si necesitamos transacciones, claves foráneas y bloqueos tendremos que escoger InnoDB por el contrario escogeremos MyISAM en aquellos casos en los que predominen las consultas SELECT a la base de datos (un gran número de páginas webs).

Mais comme il y a peu de chances que tu lises l'español, je vais te traduire ça vite fait

Avantages: MyISAM vs InnoDB
InnoDB

* Support des transactions
* Verrouillage au niveau ligne
* Offre les caractéristiques ACID (Atomicity, Consistency, Isolation and Durability), en garantissant l'intégrité des tables.
* Il est probable que si l'application fait un usage élevé d'INSERT et d'UPDATE on observera une augmentation des performances par rapport à MyISAM.

MyISAM

* En général, vitesse plus élevée lors de l'interrogation des données.
* A recommander pour des applications où prédominent les requêtes SELECT sur les INSERT / UPDATE.
* Absence d'atomicité puisqu'il n'y a pas lieu de contrôler l'intégrité référentielle, ni de verrouiller les tables pour réaliser ces opérations. Ce qui, outre ce que nous venons de citer, accroit encore la vitesse.

Le choix reste un thème délicat s'agissant d'atteindre le meilleur rapport de qualité pour l'application concernée, en prenant les choses sous un autre angle s'il est besoin des transactions, de clés étrangères et de verrouillage de ligne il faudra choisir InnoDB dans le cas contraire, choisir MyISAM dans tous les cas de prédominance des requêtes de type SELECT (ce qui est le cas sur un grand nombre de pages du web).