j'ai une table nommée Table1 contenant plusieurs enregistrements
provenant d'un fichier nommé Fichier1.txt chargé par la commande LOAD
DATA. Je souhaiterais que les enregistrements d'une colonne (nommée
Colonne1) de cette table deviennent les champs d'une autre table nommée
Table2.
Quelle(s) commande(s) peut-on employer pour réaliser cela, si possible
à partir de la table Table1 (ce serait le mieux), sinon à partir du
fichier Fichier1.txt éventuellement modifié ?
j'ai une table nommée Table1 contenant plusieurs enregistrements
provenant d'un fichier nommé Fichier1.txt chargé par la commande LOAD
DATA. Je souhaiterais que les enregistrements d'une colonne (nommée
Colonne1) de cette table deviennent les champs d'une autre table nommée
Table2.
Quelle(s) commande(s) peut-on employer pour réaliser cela, si possible
à partir de la table Table1 (ce serait le mieux), sinon à partir du
fichier Fichier1.txt éventuellement modifié ?
j'ai une table nommée Table1 contenant plusieurs enregistrements
provenant d'un fichier nommé Fichier1.txt chargé par la commande LOAD
DATA. Je souhaiterais que les enregistrements d'une colonne (nommée
Colonne1) de cette table deviennent les champs d'une autre table nommée
Table2.
Quelle(s) commande(s) peut-on employer pour réaliser cela, si possible
à partir de la table Table1 (ce serait le mieux), sinon à partir du
fichier Fichier1.txt éventuellement modifié ?
on 8/04/2004 20:15, Denis Bitouzé wrote :
> j'ai une table nommée Table1 contenant plusieurs enregistrements
> provenant d'un fichier nommé Fichier1.txt chargé par la commande
> LOAD DATA. Je souhaiterais que les enregistrements d'une colonne
> (nommée Colonne1) de cette table deviennent les champs d'une autre
> table nommée Table2.
insert into table2 (colonne_voulue) select colonne1 from table1;
on 8/04/2004 20:15, Denis Bitouzé wrote :
> j'ai une table nommée Table1 contenant plusieurs enregistrements
> provenant d'un fichier nommé Fichier1.txt chargé par la commande
> LOAD DATA. Je souhaiterais que les enregistrements d'une colonne
> (nommée Colonne1) de cette table deviennent les champs d'une autre
> table nommée Table2.
insert into table2 (colonne_voulue) select colonne1 from table1;
on 8/04/2004 20:15, Denis Bitouzé wrote :
> j'ai une table nommée Table1 contenant plusieurs enregistrements
> provenant d'un fichier nommé Fichier1.txt chargé par la commande
> LOAD DATA. Je souhaiterais que les enregistrements d'une colonne
> (nommée Colonne1) de cette table deviennent les champs d'une autre
> table nommée Table2.
insert into table2 (colonne_voulue) select colonne1 from table1;
on 8/04/2004 21:30, Denis Bitouzé wrote :
> Ce que je voudrais, c'est que les enregistrements de la colonne
> Colonne1 de la table Table1 deviennent des CHAMPS de la table
> Table2.
ah ok... en sql je vois pas
le plus simple est de faire une macro dans un editeur texte, qui va
te constituer les ALTER TABLE ad hoc
on 8/04/2004 21:30, Denis Bitouzé wrote :
> Ce que je voudrais, c'est que les enregistrements de la colonne
> Colonne1 de la table Table1 deviennent des CHAMPS de la table
> Table2.
ah ok... en sql je vois pas
le plus simple est de faire une macro dans un editeur texte, qui va
te constituer les ALTER TABLE ad hoc
on 8/04/2004 21:30, Denis Bitouzé wrote :
> Ce que je voudrais, c'est que les enregistrements de la colonne
> Colonne1 de la table Table1 deviennent des CHAMPS de la table
> Table2.
ah ok... en sql je vois pas
le plus simple est de faire une macro dans un editeur texte, qui va
te constituer les ALTER TABLE ad hoc
SI c'est saisi dans un tableur, tu peux faire une transposition avant
d'exporter vers MySql, non ?..
SI c'est saisi dans un tableur, tu peux faire une transposition avant
d'exporter vers MySql, non ?..
SI c'est saisi dans un tableur, tu peux faire une transposition avant
d'exporter vers MySql, non ?..
non, ca semble etre un bon systeme,
mais pourquoiu vouloir a tout
prix rendre les champs de Table2 dynamiques ?
On peut tres bien imaginer avoir une table generique avec 50
question, et n'en utiliser qu'une partie lors du remplissage
il serait egalement interessant de pouvoir introduire un ID de
questionnaire, dans les 2 tables
Table1 cotniendrait alors :
id_questionnaire | intitule | pts
et Table 2 :
id_questionnaire | id_etudiant | Q1 | Q2 | Qn
on obtient donc une structure qui peut accueillir plusieurs
questionnaires, et surtout independante du nombre de questions
non, ca semble etre un bon systeme,
mais pourquoiu vouloir a tout
prix rendre les champs de Table2 dynamiques ?
On peut tres bien imaginer avoir une table generique avec 50
question, et n'en utiliser qu'une partie lors du remplissage
il serait egalement interessant de pouvoir introduire un ID de
questionnaire, dans les 2 tables
Table1 cotniendrait alors :
id_questionnaire | intitule | pts
et Table 2 :
id_questionnaire | id_etudiant | Q1 | Q2 | Qn
on obtient donc une structure qui peut accueillir plusieurs
questionnaires, et surtout independante du nombre de questions
non, ca semble etre un bon systeme,
mais pourquoiu vouloir a tout
prix rendre les champs de Table2 dynamiques ?
On peut tres bien imaginer avoir une table generique avec 50
question, et n'en utiliser qu'une partie lors du remplissage
il serait egalement interessant de pouvoir introduire un ID de
questionnaire, dans les 2 tables
Table1 cotniendrait alors :
id_questionnaire | intitule | pts
et Table 2 :
id_questionnaire | id_etudiant | Q1 | Q2 | Qn
on obtient donc une structure qui peut accueillir plusieurs
questionnaires, et surtout independante du nombre de questions
on 9/04/2004 16:29, Denis Bitouzé wrote :
> On pourrait certes imaginer un table par
> épreuve de la forme suivante :
ca qui veut dire une nouvelle table par epreuve... c'est pas vraiment
l'ideal si on veut travailler avec des bases
> id_intitule intitule_exact pts
> ---------------------------------
> Q1 I.1 2
> et une table de correction associée à cette épreuve de la forme :
>
> id_etudiant Q1 Q2 ... Qn
> -----------------------------
> 1 10 50 ... 100
> 2 70 40 ... 50
oui, c'est mieux de proceder de cette facon
avoir une structure fixe, et des données variables (evidemment ;)
il vaut mieux prevoir une table contenant suffisamment de colonnes
"questions", mais simplifiant grandement le systeme, que d'imaginer
une usine a gaz, qui au final ne servirait qu'une seule fois par an
parce qu'une epreuve a 101 questions au lieu des 100 prevues...
prevois 100 questions... si un jour il en faut plus, il est facile de
rajouter des colonnes
ca depend comme seront traitees les données
a priori ca ne devrait pas poser de probleme
> Par ailleurs, s'il est vrai qu'on n'est plus tributaire du nombre
> de questions, on reste tributaire du nombre >maximum< de questions,
> non ?
oui, il faut determiner un maximum qui ne sera jamais atteint
(un peu comme quand on determine la taille d'un varchar)
on 9/04/2004 16:29, Denis Bitouzé wrote :
> On pourrait certes imaginer un table par
> épreuve de la forme suivante :
ca qui veut dire une nouvelle table par epreuve... c'est pas vraiment
l'ideal si on veut travailler avec des bases
> id_intitule intitule_exact pts
> ---------------------------------
> Q1 I.1 2
> et une table de correction associée à cette épreuve de la forme :
>
> id_etudiant Q1 Q2 ... Qn
> -----------------------------
> 1 10 50 ... 100
> 2 70 40 ... 50
oui, c'est mieux de proceder de cette facon
avoir une structure fixe, et des données variables (evidemment ;)
il vaut mieux prevoir une table contenant suffisamment de colonnes
"questions", mais simplifiant grandement le systeme, que d'imaginer
une usine a gaz, qui au final ne servirait qu'une seule fois par an
parce qu'une epreuve a 101 questions au lieu des 100 prevues...
prevois 100 questions... si un jour il en faut plus, il est facile de
rajouter des colonnes
ca depend comme seront traitees les données
a priori ca ne devrait pas poser de probleme
> Par ailleurs, s'il est vrai qu'on n'est plus tributaire du nombre
> de questions, on reste tributaire du nombre >maximum< de questions,
> non ?
oui, il faut determiner un maximum qui ne sera jamais atteint
(un peu comme quand on determine la taille d'un varchar)
on 9/04/2004 16:29, Denis Bitouzé wrote :
> On pourrait certes imaginer un table par
> épreuve de la forme suivante :
ca qui veut dire une nouvelle table par epreuve... c'est pas vraiment
l'ideal si on veut travailler avec des bases
> id_intitule intitule_exact pts
> ---------------------------------
> Q1 I.1 2
> et une table de correction associée à cette épreuve de la forme :
>
> id_etudiant Q1 Q2 ... Qn
> -----------------------------
> 1 10 50 ... 100
> 2 70 40 ... 50
oui, c'est mieux de proceder de cette facon
avoir une structure fixe, et des données variables (evidemment ;)
il vaut mieux prevoir une table contenant suffisamment de colonnes
"questions", mais simplifiant grandement le systeme, que d'imaginer
une usine a gaz, qui au final ne servirait qu'une seule fois par an
parce qu'une epreuve a 101 questions au lieu des 100 prevues...
prevois 100 questions... si un jour il en faut plus, il est facile de
rajouter des colonnes
ca depend comme seront traitees les données
a priori ca ne devrait pas poser de probleme
> Par ailleurs, s'il est vrai qu'on n'est plus tributaire du nombre
> de questions, on reste tributaire du nombre >maximum< de questions,
> non ?
oui, il faut determiner un maximum qui ne sera jamais atteint
(un peu comme quand on determine la taille d'un varchar)
on 9/04/2004 17:26, Denis Bitouzé wrote :
>>ca qui veut dire une nouvelle table par epreuve... c'est pas
>vraiment>l'ideal si on veut travailler avec des bases
>
> Euh, excuse-moi, peux-tu préciser ? Je ne vois pas pourquoi...
si tes intitulés changent, les colonnes de ta table2 changeront aussi
pas dans le cas ou tu utilises un ID de type "Q x" et une
correspondance au niveau de la table1 comme ici :
ceci dit, si tu prevois de faire tourner tout ca sur un serveur web,
on peut imaginer que c'est un script (perl, php, etc...) qui genere
la table2 pour chaque nouvelle table1 donnée
mais, amha, on peut s'en sortir avec une structure generique
de rien, c'est une reflexion interessante
on 9/04/2004 17:26, Denis Bitouzé wrote :
>>ca qui veut dire une nouvelle table par epreuve... c'est pas
>vraiment>l'ideal si on veut travailler avec des bases
>
> Euh, excuse-moi, peux-tu préciser ? Je ne vois pas pourquoi...
si tes intitulés changent, les colonnes de ta table2 changeront aussi
pas dans le cas ou tu utilises un ID de type "Q x" et une
correspondance au niveau de la table1 comme ici :
ceci dit, si tu prevois de faire tourner tout ca sur un serveur web,
on peut imaginer que c'est un script (perl, php, etc...) qui genere
la table2 pour chaque nouvelle table1 donnée
mais, amha, on peut s'en sortir avec une structure generique
de rien, c'est une reflexion interessante
on 9/04/2004 17:26, Denis Bitouzé wrote :
>>ca qui veut dire une nouvelle table par epreuve... c'est pas
>vraiment>l'ideal si on veut travailler avec des bases
>
> Euh, excuse-moi, peux-tu préciser ? Je ne vois pas pourquoi...
si tes intitulés changent, les colonnes de ta table2 changeront aussi
pas dans le cas ou tu utilises un ID de type "Q x" et une
correspondance au niveau de la table1 comme ici :
ceci dit, si tu prevois de faire tourner tout ca sur un serveur web,
on peut imaginer que c'est un script (perl, php, etc...) qui genere
la table2 pour chaque nouvelle table1 donnée
mais, amha, on peut s'en sortir avec une structure generique
de rien, c'est une reflexion interessante
