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:
 

 
MERCI D'AVANCE

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

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

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
 
Peut-être la solution serait de faire une requete de type "INSERT ... SELECT" ???

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

INSERT ... SELECT ??

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

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.  
 

 
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
 

 
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...

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.

faites votre choix:
 
entre

et

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

je vote  
 

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  

+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 ...
 
 

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

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.

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.

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

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ésolé

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":

car

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!

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.

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 :

 
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.

CQFD Bravo

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

 
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.