[SQL] Requete INSERT dans plusieurs tables liées

Requete INSERT dans plusieurs tables liées [SQL] - SQL/NoSQL - Programmation

Marsh Posté le 04-03-2004 à 19:13:51    

Bonjour,
 
je démarre une FAQ dynamique, et g un problème pour pouvoir insérer mes champs de formulaire dans ma base...
 
Voici une ptite image afin d'illustrer la chose:
 
ftp://ftp2.teamindamix.com/teaminda/man/INSERT-bdd.gif
 
MERCI D'AVANCE


Message édité par lkolrn le 27-04-2004 à 22:49:42
Reply

Marsh Posté le 04-03-2004 à 19:13:51   

Reply

Marsh Posté le 04-03-2004 à 19:25:52    

tu dois insérer table par table. de plus la relation idrubrique est fausse (c'est 1 - 1,n)


---------------
What if I were smiling and running into your arms? Would you see then what I see now?  
Reply

Marsh Posté le 04-03-2004 à 20:40:52    

C'est quoi la question ?
 
Il faut que les champs correspondant dans les tables user et rubrique existent avant de pouvoir insérer un message. Mais je pense pas que ca pose problème :??:

Reply

Marsh Posté le 05-03-2004 à 01:13:35    

Citation :

la relation idrubrique est fausse (c'est 1 - 1,n)


une rubrique contient 1 à n messages, et un message peut aussi être contenu dans 1 à n rubriques ( :??: )
 
La table rubrique, c po trop la question ici puisqu'il n'y a pas de rubrique dans le formulaire...
 
Par contre, si j'arrive à savoir comment lier à l'insertion l'IDuser, clé primaire (numéro auto-incrémenté) de la table USER, avec l'IDuser, clé etrangère de la table MESSAGE, bah ca marchera pareil avecla table RUBRIQUE.
 
En fait j'enregistre le nom et le mail de l'user, mais je dois aussi faire correspondre l'id de l'user avec celui du message, et comme g jamais fais ca en MySQL, ca bloque là-haut :pt1cable:
 
Peut-être la solution serait de faire une requete de type "INSERT ... SELECT" ???


Message édité par lkolrn le 05-03-2004 à 01:17:12
Reply

Marsh Posté le 05-03-2004 à 09:00:44    

n'importe quoi.  
 
1) pour avoir le dernier ID, il faut utiliser une fonction MySQL du style get_last_id() (je suis plus certain)
 
2) Peut-être la solution serait de faire une requete de type "INSERT ... SELECT" ???
   --> sans commentaire. ce type de requête n'existe pas
 
3) une relation 1,n - 1,n demande une table de jointure. ce qui n'est pas le cas ici. Surtout qu'avec idRubrique on est CLAIREMENT dans le cas d'une simple 1 - 1,n


---------------
What if I were smiling and running into your arms? Would you see then what I see now?  
Reply

Marsh Posté le 05-03-2004 à 09:30:40    

JagStang a écrit :

n'importe quoi.  
 
 
2) Peut-être la solution serait de faire une requete de type "INSERT ... SELECT" ???
   --> sans commentaire. ce type de requête n'existe pas


 
 :heink:

Reply

Marsh Posté le 05-03-2004 à 09:56:42    

INSERT ... SELECT ??


---------------
What if I were smiling and running into your arms? Would you see then what I see now?  
Reply

Marsh Posté le 05-03-2004 à 10:13:44    

JagStang a écrit :

INSERT ... SELECT ??  


 
 
insert into tablexxxx (field1, field2) select field1, field2 from tableyyyyy where .....


Message édité par red faction le 05-03-2004 à 10:14:14
Reply

Marsh Posté le 05-03-2004 à 10:23:31    

peut-on apparenter ça à une sous-requête ?
 
dans tout les cas, le problème étant de faire correspondre avec l'ID auto_incrementé, ma solution comvient.  
 


---------------
What if I were smiling and running into your arms? Would you see then what I see now?  
Reply

Marsh Posté le 05-03-2004 à 10:59:34    

Citation :

Peut-être la solution serait de faire une requete de type "INSERT ... SELECT" ???
--> sans commentaire. ce type de requête n'existe pas


 
t'as bien raison de t'abstenir d'en faire sur ce coup la:
http://www.mysql.com/doc/en/INSERT_SELECT.html
si jamais t'as du mal:
http://www.mysql.com/doc/fr/INSERT_SELECT.html
 

Citation :

une relation 1,n - 1,n demande une table de jointure. ce qui n'est pas le cas ici. Surtout qu'avec idRubrique on est CLAIREMENT dans le cas d'une simple 1 - 1,n


 
En Merise, je connais seulement la cardinalité 1,1 mais 1 tout court, nan...
Par exemple, un message ne peut être posté que par une et une seule personne (relation 1,1), mais je ne vois pas pourquoi un même message ne pourrait pas être inséré dans plusieurs rubriques (s'il traite de plusieurs thèmes différents => implique relation 1,N)
 
Je comprend par ailleurs que chaque clé étrangère IDrubrique (contenue dans table MESSAGE) est unique (d'ou relation 1,1), mais rien n'empeche en théorie d'avoir plusieurs enregistrement identiques dans MESSAGE, avec seulement l'IDrubrique qui varie (quand le sujet concerne plusieurs rubriques)
 
Après jme plante ptet, g po la science infuse, mais si tu réponds seulement c (1,1-N) PASKE c (1,1-N), ca risque po d'avancer...


Message édité par lkolrn le 05-03-2004 à 11:58:22
Reply

Marsh Posté le 05-03-2004 à 10:59:34   

Reply

Marsh Posté le 05-03-2004 à 12:59:41    

si tu as vraiment 1,n - 1,n alors il te manque une table de jointure regroupant les paires d'identifiants. j'ai pas non plus la science infuse. Mais ça me parait logique.  
 
Mea Culpa pour le insert select.


---------------
What if I were smiling and running into your arms? Would you see then what I see now?  
Reply

Marsh Posté le 10-03-2004 à 02:16:25    

faites votre choix:
 
entre

Citation :

une table de jointure regroupant les paires d'identifiants


et

Citation :

avoir plusieurs enregistrement identiques dans MESSAGE, avec seulement l'IDrubrique qui varie (quand le sujet concerne plusieurs rubriques)


quelle est la solution la - emcombrante en mémoire et/ou la + rapide à l'execution :??: (au dela de la "logique" ;p)
 
note: en Merise la table de jointure est apparemment préconisée dans une relation reciproque (1,N)-(1,N), alors qu'il parait aussi possible d'utiliser plusieurs (ici 3) cles primaires...
 
Je ne c quoi en pan c :pt1cable:


Message édité par lkolrn le 10-03-2004 à 02:28:46
Reply

Marsh Posté le 10-03-2004 à 02:30:09    

je vote  
 

Citation :


une table de jointure regroupant les paires d'identifiants


 
:)


---------------
What if I were smiling and running into your arms? Would you see then what I see now?  
Reply

Marsh Posté le 10-03-2004 à 09:20:29    

le probleme c qui faut tout decouper par apres a la main genre :  
 
Client  Commande
76       5898
76       3245
76       7984
77       1277
77       8914
 
 
 
avec le bon vieux truc du oldclientid et currentclientid de facon a distinguer se qui va ensemble  
 
qd ya plusieurs colonnes comme ca  :cry:

Reply

Marsh Posté le 10-03-2004 à 10:15:54    

+1 Jagstang
 
Moi je pencherais, si le blème est toujours d'actualité
pour ... la paire d'Identifiant
=>
User(Iduser, ...)
Msg(Idmsg ..., *idUser)
Rub(Idrub, nom)
Concern_msg_rub(*Idmsg,*Idrub)
 
Donc pour un message on a un et un seul User
mais ce message peut entrer dans 1 à plusieurs rubriques
 
Après niveau place, rapidité ... il faut savoir  
combien yaura de User et de messages grosso modo +
s'il y aura un historisation ...
 
 

Reply

Marsh Posté le 10-03-2004 à 10:19:54    

JagStang a écrit :


2) Peut-être la solution serait de faire une requete de type "INSERT ... SELECT" ???
   --> sans commentaire. ce type de requête n'existe pas


Il utilise pas forcément MySQL (en tout cas, c'est pas marqué...) et INSERT ... SELECT ... existe :o

Reply

Marsh Posté le 10-03-2004 à 10:21:34    

LKoLRn a écrit :

Citation :

la relation idrubrique est fausse (c'est 1 - 1,n)


une rubrique contient 1 à n messages, et un message peut aussi être contenu dans 1 à n rubriques ( :??: )


A ce moment, il manque une table de correspondance "message_rubrique" avec ID_RUBRIQUE et ID_MESSAGE, c'est le seul moyen de gérer une relation 1,n - 1,n dans un MCD. Ton MPD est faux.

Reply

Marsh Posté le 10-03-2004 à 10:23:49    

Sinon, pour en revenir à la question initiale, t'as pas d'autre choix que de faire un INSERT par table, et récupérer les ID générés dont tu as besoin. Tout SGBD digne de ce nom (même MySQL, c'est pour dire !) le permet.

Reply

Marsh Posté le 10-03-2004 à 11:17:18    

MagicBuzz a écrit :


Il utilise pas forcément MySQL (en tout cas, c'est pas marqué...) et INSERT ... SELECT ... existe :o


Lis plus haut, j'ai déjà fait mon mea culpa. je ne savais pas que ça existait en MySQL


---------------
What if I were smiling and running into your arms? Would you see then what I see now?  
Reply

Marsh Posté le 10-03-2004 à 16:21:52    

J'avoue que comme souvent, je répond au fur et à mesure que je lis le topic, donc j'avais pas vu les réponses suite à ce que t'avais dit :D Désolé ;)

Reply

Marsh Posté le 11-03-2004 à 01:03:20    

Citation :

Il utilise pas forcément MySQL (en tout cas, c'est pas marqué...)

euh... dans www.mysql.com/doc/en/INSERT_SELECT.html, ya www.mysql.com :)
 
Vous avez choisi: apparemment il est nécessaire de faire une table de jointure dans une relation (1,N)-(1,N)
 
Mais je reviens moi aussi a la 2eme question car c "important":

Citation :

Je ne c quoi en pan c :pt1cable:


car

Citation :

il parait aussi possible d'utiliser plusieurs (ici 3) cles primaires...


qui seraient les attributs userID, msgID et rubrikID de la table MESSAGE (chaque message est caractérisé par un utilisateur ET une rubrique, donc un meme message peut etre posté par le meme user dans plusieurs rubriques différentes, nan?;))  
 
Est-ce possible (meme s'il peut y avoir redondance d'information) ou bien carrément faux :??:
 
note: je c je cherche la petite bete! :p


Message édité par lkolrn le 11-03-2004 à 01:14:23
Reply

Marsh Posté le 11-03-2004 à 01:30:44    

c'est clair qu'il y a redondance. comme dans le messageID, tu as les deux autres ID, pourquoi les stocker ?
 
en FN 3 (sauf erreur) c'est comme ça qu'on fait
 
on ne stock jamais des informations qu'on peut avoir par calcul, ou en faisant des jointures etc.
 
par exemple, il ne faut pas stocker le total d'une facture, car il est calculable.


---------------
What if I were smiling and running into your arms? Would you see then what I see now?  
Reply

Marsh Posté le 11-03-2004 à 10:09:00    

LKoLRn > Moi j'ai juste dit que t'avais pas précisé le SGBD que tu utilisais, et que donc pour te répondre on ne pouvait pas prendre en compte d'office les éventuelles limitations de MySQL, car c'est quelque-peu réducteur, surtout si tu utilises un autre SGBD plus puissant.
 
Sinon, tu as indiqué qu'un même message pouvait être dans plusieurs rubriques. D'où la relation 1,n / 1,n dans le MCD, dont l'apparition d'une table de jointure dans le MPD, c'est inévitable.
Par contre, si un même message n'a qu'une seule rubbrique possible, alors ça devient une bête CIF, et ça se traduit par une clé étrangère toute bête comme tu l'as déjà fait.
 
JagStang > La théorie c'est bien. MERISE est très fort pour ça. Mais une phase très importante de l'analyste, c'est de dénormaliser le modèle des données une fois l'analyse terminée avec les outils de normalisation.
Pour un total de facture, en effet, la donnée est beaucoup trop sensible pour être stockée... Par contre, pour un paiement par exemple, il va systématiquement stocker le montant total payé, et non pas un flag "payé/pas payé". Parceque si la facture est modifiée par le programme par la suite, il faut s'assurer que le client a payé ce qu'il devait, et non pas plus ou moins.
 
Autre exemple de dénormalisation.
 
Dans l'ERP Generix, on a une table EVE, qui contient les commandes, les factures, les devis, et tout un tas d'autres informations.
Il y a ensuite une table EVL qui contient, pour chaque ligne de EVE, le détail (les lignes), et dans EVP, les sous-lignes des lignes de EVL (expéditions, paiements, etc.)
Eh bien dans EVL et EVP, un très grand nombre d'information sont systématiquement dupliquées, par exemple le client, le type d'évènement, des informations à propos de la tarification, etc. qui sont pourtant globales à la commande.
 
Pourquoi ?
 
Réponse :


SQL> select count(*) from eve;
 
 COUNT(*)
---------
  1311215
 
SQL> select count(*) from evl;
 
 COUNT(*)
---------
  3484527
 
SQL> select count(*) from evp;
 
 COUNT(*)
---------
  3391164
 
SQL>  


 
Maintenant, je désire retrouver le détail de toutes les expéditions pour les commandes vente du client 000007 pour le produit 1A00473...
 
Ca donnerait, sans ces infos dupliquée :
 
select evp.*
from eve, evl, evp
where eve.achvte = 'V' and eve.sigtie = '000007' and eve.typtie = 'CLI'
and evl.numeve = eve.numeve
and evl.codpro = '1A00473'
and evp.numevl = evl.numevl
 
Super, je me tape : 1311215 * 3484527 * 3391164 = 1,5 * 10^18 lignes à scanner !
 
En dupliquant ces informations qui sont systématiquement utilisées jusque dans EVP, je n'ai plus que 3391164 scans à faire.
 
Index ou pas, ce sera forcément infiniement plus rapide si j'évite de faire des jointures entre des tables aussi volumineuses.

Reply

Marsh Posté le 11-03-2004 à 11:59:40    

CQFD Bravo


---------------
What if I were smiling and running into your arms? Would you see then what I see now?  
Reply

Marsh Posté le 11-03-2004 à 13:47:51    

MERCI BIEN pour vos réponses :jap:  
maintenant je m'y colle pour de bon :)

Reply

Marsh Posté le 26-04-2004 à 18:45:35    

LKoLRn a écrit :

Bonjour,
 
je démarre une FAQ dynamique, et g un problème pour pouvoir insérer mes champs de formulaire dans ma base...
 
Voici une ptite image afin d'illustrer la chose:
 
ftp://ftp2.teamindamix.com/teamin [...] RT-bdd.gif
 
MERCI D'AVANCE

Reply

Marsh Posté le 27-04-2004 à 07:51:04    

MagicBuzz a écrit :



SQL> select count(*) from eve;
 
 COUNT(*)
---------
  1311215
 
SQL> select count(*) from evl;
 
 COUNT(*)
---------
  3484527
 
SQL> select count(*) from evp;
 
 COUNT(*)
---------
  3391164
 
SQL>  


 
Maintenant, je désire retrouver le détail de toutes les expéditions pour les commandes vente du client 000007 pour le produit 1A00473...
 
Ca donnerait, sans ces infos dupliquée :
 
select evp.*
from eve, evl, evp
where eve.achvte = 'V' and eve.sigtie = '000007' and eve.typtie = 'CLI'
and evl.numeve = eve.numeve
and evl.codpro = '1A00473'
and evp.numevl = evl.numevl
 
Super, je me tape : 1311215 * 3484527 * 3391164 = 1,5 * 10^18 lignes à scanner !
 
En dupliquant ces informations qui sont systématiquement utilisées jusque dans EVP, je n'ai plus que 3391164 scans à faire.
 
Index ou pas, ce sera forcément infiniement plus rapide si j'évite de faire des jointures entre des tables aussi volumineuses.


 
mouais ...
enfin tout dépend du soft qui fait la requête !
si les tables sont indexées sur les champs par lesquels tu accèdes (eve.achvte, eve.sigtie, eve.typtie, evl.numeve, eve.numeve, evl.codpro, evp.numevl, evl.numevl), alors tu ne scanneras jamais la totalité des tables, mais juste une infime partie de chaque, et la jointure sera extrêmement rapide :)
 
"En dupliquant ces informations qui sont systématiquement utilisées jusque dans EVP, je n'ai plus que 3391164 scans à faire."
-> à mon avis, tu ne les fais même pas, s'il y a les bons indexes.

Reply

Marsh Posté le    

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed