non.
Tu ne comprends rien.
Il faut dire que je ne suis pas clair, certainement, mais bon.
Je n'ai evidemment JAMAIS parle de construire une table par produit
J'ai dit:
Citation :
A, B, C, D etc sont les caracteristiques d'un produit. Un produit se definit par son nom et l'ensemble de ses caracteristiques.
Un produit est donc identifie de facon unique par ses caracteristiques.
|
Ce n'est pas une table par produit mais une table par caracteristique.
bon, on va donne run exemple tres explicite parce qu'on ne se comprend pas.
Un produit chimique peut etre produit dans le laboratoire Dupont, Dubois ou Duchmoll. Il a subi un test de qualite, le Z23, le H12 ou le A01. Il est achetable par le type de contrat "p60j", "p30j" ou "comptant".
De facon tres evidente, tu ne me diras pas le contraire, j'ai trois tables pour les caracteristiques. En effet, j'ai besoin par ailleurs d'avoir une table sur les carac d'un labo, une sur les caracs de chaque type de contrat et une sur les protocoles correspondant a chaque test.
Nous avons donc une table produit, qui contient 3 champs cles etrangeres, ainsi qu'un nom plus ou moins aleatoire, genre ZI567-B5 (c'est un compose chimique unique definit par toutes ses caracs car la meme composition chimique theorique donne un resultat pratuique different suivant le labo etc).
Je veux assurer l'unicite de chaque entree, et ne pas avoir plusieurs denominations pour un meme produit.
Tu me dis que je n'utilise pas un index unique, mais un systeme de cle primaire compose de l'integralite des champs.
Soit.
Mon produit chimique n'est donc pas identifie par un entier unique, mais par une combinaison unique de caracteristiques.
Jusque la ca va? Nous avons donc, au bas mot, 3 champs comme cle primaire.
Maintenant, reprenons nos personnes.
Nous avons clairement une table "individus" contenant une cle primaire entiere auto-incrementee identifiant de facon unique chaque individu de la table.
Ensuite, on veut tenir l'inventaire de ce que chacun a en stock.
Nous avons donc une table "possede" dont les entrees sont des triplets (personne, produit, quantite).
Comme tu as dit que la cle de "produit", c'etait un ensemble de 3 champs, cela signifie donc que la cle de chaque entree de "possede" est individu*labo*test*contrat.
Ce qui est assez peu pratique.
Ton exemplke n'est pas eclairant, puisque tu t'abstraits precisement de la question que je pose.
dans ton exemple, la table "produit" a une cle primaire constituee d'un seul champ. Donc bien evidemment il n'y a pas de probleme, puisque l'hypothese de depart est qu'il y en a plusieurs et que ce n'est pas le cas dans ton exemple.
Peut-etre es-tu en train de me dire que ton exemple permet justement d'eviter qu'il y en ait plusieurs, mais dans ce cas la tu es en train de faire exactement ce que tu me deconseillais: tu m'as dit que si qqch est determine par plusieurs champs, tous doivent etre utilises comme cle primaire et qu'on evite d'avoir recours a un id autre.
Or la ce n'est pas ce que tu as fait.
Dans ton cas, tu es en train de me dire que ta table type_produit regroupe les infos labo/contrat/test.
OK, mais alors pourquoi lui as-tu mis une cle primaire constituee d'un seul champ? Je veux toujours, quel que soit le nombre de tables intermediaires, avoir l'unicite du triplet (labo, contrat, test), ce qui n'est pas assure avec ta table puisque ces champs ne constituent pas la cle primaire.
Et s'ils la constituaient en lieu et place de id_type, eh bien dans ce cas, tu aurais dans "produit" tous les champs primaires de type_produit, et pour assurer l'unicite, tu devrais les inclure dans la cle, et donc etc...
Desole de contester ainsi, j'ai certainement tort, mais ca reste tout sauf clair.
Dans tous les cas, je te remercie beaucoup pour ton temps, j'apprecie meme si j'ai l'air de ne pas etre d'accord avec ce que tu dis.