Bon, apres une longue et infructueuse recherche, je n'arrive pas a trouver une explication claire et simple des cas ou l'on utilise une cle multiple (terme exact?) de ceux ou on utilise un unique index.
 
Ce n'est jamais dit clairement.
 
Imaginons, j'ai ma  
- table Nom avec idNom, Nom
- ma table adresse avec idAdresse, Adresse
- une table habite contenant Nom.idNom, Adresse.idAdresse, et eventuellement (ca fait partie de la question) idhabite.
 
Je veux que plusieurs personnes puissent habiter le meme endroit, qu'une personne puisse avoir plusieurs residences, mais je ne veux pas qu'il y ait plusieurs fois la meme personne a la meme adresse.
 
Que dois-je faire?
Index unique, cle unique, cles secondaires, cle primaire ou pas de cle primaire?
 
Merci bcp

Bon déjà tu utilises certains termes qui sont inexacts. Les index, c'est une autre notion, différente de celle des clés primaires que tu verras sans doute plus tard . Autrement les clés secondaires c'est quoi pour toi (des clés étrangères?) ?  
 
Pour ta base, les champs idNom et idAdresse des tables Nom et Adresse sont des clés primaires car ils identifient de manière unique un enregistrement précis dans la table (mais j'imagine que ça tu l'avais déjà compris).
 
Reste le cas de ta table intermédiaire. Cette table est nécessaire puisque comme tu le dis "plusieurs personnes peuvent habiter le meme endroit et une personne peut avoir plusieurs residences". Si on n'avait qu'une personne par maison, ou une maison par personne, ça n'aurait pas été le cas, il aurait suffit de faire une clé étrangère dans l'une de tes deux tables.
 
Pour déterminer si tu dois mettre un couple ou non, tu dois te poser la question : "est-il possible d'identifier un enregistrement de manière unique à partir des champs de ma table ?". Ici, c'est le cas en mettant une clé primaire "double" dans la table intermédiaire. Il n'est pas possible d'avoir de doublons puisque sinon on a une redondance d'informations.
 
Un exemple permet d'y voir plus clair :
Dans la table Nom on met:
1 | Dupont
2 | Martin
Dans la table adresse:
1 | Rue des fleurs
2 | Avenue CDG
3 | Rue hardware.fr
etc.
Dupont a deux résidences, on met donc dans la table intermédiaire
idNom | idAdresse
 1    |   1
 1    |   2
 
Martin habite avec Dupont et a une résidence secondaire dans la rue HFR
idNom | idAdresse
 1    |   2
 1    |   3
 
Il n'est pas utile de mettre deux fois l'information "Dupont habite rue des fleurs" (redondance) donc un couple de clés primaire est parfait pour ta table intermédiaire.
 
Enfin, pour éviter les incohérences au niveau de la base de données, et être sûr que par exemple un nom est associé à un couple (nom, adresse), on met deux clés étrangères comme ceci :

 
Cette étape évite d'avoir des incohérences au niveau de la base. Imagine, par exemple qu'on supprime Dupont, il faut s'assurer qu'il n'a pas des adresses associées, et les clés étrangères permettent de s'en prémunir.

ok ca j'ai bien compris
Je te remercie.
Mais mon probleme reste entier en fait.
Comme tu le dis, j'utilise des termes faux ou approximatifs. Je comprend tres bien ce que je dois faire comme jointures etc pour ma base (qui contient 13 tables avec un bon paquets de jointures dans tous les sens).
 
Mais du coup je ne comprend toujours pas ce que je dois faire exactement au niveau des cles. Comment je fais pour mettre une cle primaire double?
Est-ce que du coup je suis oblige d'eviter d'avoir un idhabite integer autoincrement, qui est par ailleurs bien pratique meme si j'identifie de facon certaine avec un couple de cles etrangeres?
 
Bref, je te remercie de ton aide, et si tu peux me donner le create table qui va bien pour cet exemple simple, peut-etre que ca sera plus clair pour moi. Par exemlpe si je veux qu'habite contienne une cle primaire integer tout ca, et en plus rendre unique le couple nom-adresse, si c'est possible, ou bien en n'ayant pas de compteur qui fasse cle primaire si ce n'est pas possible.

merci beaucoup en tout cas

Mais du coup je ne comprend toujours pas ce que je dois faire exactement au niveau des cles. Comment je fais pour mettre une cle primaire double?

 
Au moment de la création de la table, c'est très simple il suffit de mettre deux PRIMARY KEY au lieu d'une pour le CREATE TABLE.
 
Est-ce que du coup je suis oblige d'eviter d'avoir un idhabite integer autoincrement, qui est par ailleurs bien pratique meme si j'identifie de facon certaine avec un couple de cles etrangeres?
 
Dans les tables Adresse et Nom, les clés primaires peuvent être en autoincrement. Pour la table intermédiaire c'est impossible (enfin c'est possible techniquement mais c'est une énormité car tu ne pourras pas exploiter ta table). Sinon une clé primaire idHabite unique dans ta table intermédiaire ne convient pas car comme tu l'as dit "je ne veux pas qu'il y ait plusieurs fois la meme personne a la meme adresse" (doublons). La double clé primaire évite la redondance d'infos.
 
Bref, je te remercie de ton aide, et si tu peux me donner le create table qui va bien pour cet exemple simple, peut-etre que ca sera plus clair pour moi.

J'en doute, là c'est un problème d'analyse et non de syntaxe... mais bon si tu la veux quand même il faut que tu me dises le SGBD que tu utilises. (Oracle, SQL server, etc.)
 
Par exemlpe si je veux qu'habite contienne une cle primaire integer tout ca, et en plus rendre unique le couple nom-adresse, si c'est possible, ou bien en n'ayant pas de compteur qui fasse cle primaire si ce n'est pas possible.

 
Là j'avoue que j'ai rien pigé

je pense que si, ce serait plus clair quand meme. Ca me permettra d'etre sur.
C'est du SQL (enfin, quand j'aurai reussi a trouver ou ce sette ce p... de password de easyphp de m...).
 
Comme ca je compare a ce que j'ai ecrit, et je vois (la le modele estfait, mais bon, je peux pas tester tant que j'ai pas ma config moisie).
C'est pas vraiment un probleme d'analyse, plutot un probleme de connaissance du langage pour savoir ce qu'on peut ou non faire (on pourrait imaginer deux series de cles primaires independantes, qui pourrait chacune identifier de maniere unique, et l'on pourrait appeler soit l'idhabite, soit lac ombinaison de cles etrangeres qui identifient aussi)
 
pour le dernier point, ben en gros mon propos, c'est de demander comme juste au-dessus si c'est impossible un systeme de double serie de cles (pas double cles, ca ok, double serie). Enfin, apparemment, non, donc ok.

je pense que si, ce serait plus clair quand meme. Ca me permettra d'etre sur.
C'est du SQL (enfin, quand j'aurai reussi a trouver ou ce sette ce p... de password de easyphp de m...).
 
Ca j'avais bien imaginé que c'était du SQL . Bon puisque tu parles d'easyphp, j'imagine que c'est mySQL. J'en ai jamais fait mais la syntaxe devrait être un truc du genre :
 
CREATE TABLE NOM
(idNom INTEGER AUTO_INCREMENT PRIMARY KEY,
Nom VARCHAR(100))
 
CREATE TABLE ADRESSE
(idAdresse INTEGER AUTO_INCREMENT PRIMARY KEY,
Adresse VARCHAR(100))
 
CREATE TABLE HABITE
(idNom INTEGER FOREIGN KEY NOM.idNom
idAdresse INTEGER FOREIGN KEY ADRESSE.idAdresse
CONSTRAINT PRIMARY KEY(idNom,idAdresse))
 
(m'étonnerait que ça marche hein, j'ai jamais fait de mySQL mais ça doit être un truc dans ce goût là)
 
Comme ca je compare a ce que j'ai ecrit, et je vois (la le modele estfait, mais bon, je peux pas tester tant que j'ai pas ma config moisie).
C'est pas vraiment un probleme d'analyse, plutot un probleme de connaissance du langage pour savoir ce qu'on peut ou non faire (on pourrait imaginer deux series de cles primaires independantes, qui pourrait chacune identifier de maniere unique, et l'on pourrait appeler soit l'idhabite, soit lac ombinaison de cles etrangeres qui identifient aussi)
 
Quand je lis ta dernière phrase j'ai vraiment l'impression que c'est un problème d'analyse. Je ne vois vraiment pas comment on peut gérer cette situation avec deux clés primaires indépendantes (donc deux tables).
 
pour le dernier point, ben en gros mon propos, c'est de demander comme juste au-dessus si c'est impossible un systeme de double serie de cles (pas double cles, ca ok, double serie). Enfin, apparemment, non, donc ok.

donc ok
 
edit: j'ai écrit des bêtises dans le CREATE TABLE de Habite

ben c'est un probleme de langage et pas d'analyse parce qu'on pourrait tres bien gerer ca sans probeleme logique si le langage le permettait: tout simplement j'ai deux cles primaires quiidentifient de facon unique dans une meme table: mon numero de secu, et mon numero de carte d'identitie, et chaque fois que qqn est rentre dans la trable, ben il faut absolument que ni l'un ni l'autre ne soit deja pris. Et pour les selects, tu tte fierais a l'un ou a l'autre.
 
Ca ne pose aucun probleme conceptuel, c'est juste une question de formalisme au sein du langage sql (et d'ailleurs si je le comprend bien, les UNIQUE INDEX, ca permet entre autres de pallier justement cette faiblesse. Un unique index peut bien jouer un role strictement equivalent a une cle primaire.
 
Bon, en tt cas, merci, j'ai bien compris, je vais maintenant devoir a nouveau me demander si je laisse tomber la cle primaire autoincrement (de mes tables de jointures) ou bien si j'utilise un unique index pour assurer l'unicite de mes parametres croises tout en conservant un id pouvant constituer a lui tout seul la cle primaire.

 
Donne moi le schéma de base que tu avais conçu parce que c'est pas très clair
 
Bon sinon tu peux toujours mettre une clé primaire en auto_inc dans ta table intermédiaire et mettre une contrainte d'unicité sur le couple (idNom,idAdresse) (mot clé UNIQUE dans le CREATE TABLE), mais ça n'a pas d'intérêt on obtient le même résultat avec un champs de moins (le but c'est quand même de faire la base la plus simple possible).
 
Tu peux même ne pas mettre de clé primaire du tout si tu mets le mot clé UNIQUE mais là ça devient très très moche (enfin vu que la clé primaire unique n'a pas d'utilité )

Bon, en tt cas, merci, j'ai bien compris, je vais maintenant devoir a nouveau me demander si je laisse tomber la cle primaire autoincrement (de mes tables de jointures) ou bien si j'utilise un unique index pour assurer l'unicite de mes parametres croises tout en conservant un id pouvant constituer a lui tout seul la cle primaire.
 
Tu oublies quand même une chose c'est que tu dois être sûr que les valeurs de ta base ne sont pas NULL. Tu dois donc ajouter une contrainte.
Et contrainte d'unicité + contrainte de non NULL = clé primaire   (en fait tu refais une clé primaire manuellement)

oui, exactement.
Mais c'est justement ca, si j'ai l'impression d'avoir besoin de deux series de cles primaires pour ma table (cf acces par numero de secu ET numero de carte d'identite, au choix)...
 
Enfin bon, je vais probablement laisser tomber ma cle auto-ioncrementee meme si je trouve que c'est mieux qu'un quadrinome de donnees pour identifier un enregistrement (car en l'occurence dans plusieurs de mes tables de jointure, il faut 4 champs pour faire la cle primaire)

Bon, Yonel, ca y est, c'est bien ce que je craignais, ca me semble totalement sous-optimal tout ca.
Je donne un cas plus proche de ma db pour te montrer le probleme, peut-etre auras-tu un conseil avisé a me donner
 
Table A: idA
Table B: idB
table C: jointure entre A et B
 
table D: idD
table E: idE
table F: jointure entre D et E
 
table G: jointure entre C et F
 
Du coup:
- premiere solution, chacun a sa cle primaire en interger auto-increment. On n'a a priori pas l'unicite des couples (ex: deux elements de C qui sont A/B alors que ca devrait etre unique), il faut y venir par des unique index.
Peu satisfaisant.
- deuxieme solution, on definit pour C et F des primary keys constituees de deux champs (A et B pour C, D et E pour F). OK, mais alors la primary key de la table G, elle craint a fond. Il faudrait que la table G reprenne les 4 champs pour constituer une primary key, perdant ainsi tout le poids du concept (c'est a dire que G est constitue de C et F, pas de A, B, D, et E). Tres insatisfaisant.
 
Voila, qu'ne penses-tu? Tu vois mon probleme?

 
à moins d'avoir une relation quaternaire entre tes tables (c'est très très rare... déjà qu'une qu'une ternaire c'est vraiment pas répendu), tu n'auras jamais 4 champs pour faire une clé primaire. En général (on va dire dans 90% des cas), c'est une ou deux clés primaires pour une table. Si tu ne vois pas de manière évidente d'identifier un enregistrement de manière unique, c'est une clé primaire toute simple en un seul exemplaire. C'est juste quand on a des trucs du genre "une personne peut avoir plusieurs adresses et une adresse peut être affectée à plusieurs personnes" qu'il faut une table intermédiaire avec deux clés

 
Non en fait je ne comprends pas ce que tu mets dans tes tables D, E, F et surtout G. Tu pourrais pas mettre un texte explicatif que ce soit plus clair ?

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.
 
Z est un ensemble de personnes.
 
Je veux tenir le compte de quelle personne possede combien de chaque type de produit (enfin, c'est une petite partie de ma db, il y a aussi qui les produit, a quel cout, comment, a partir de quels autres produits etc mais je passe sur la complexite, deja ca ca suffit pour avoir le probleme).
 
Il me faut une table T qui de facon evidente contient des couples uniques personne/produit (avec un nombre associe pour chaque).
Oui, mais...
 
Puisque tu dis que le produit ne doit pas avoir une cle primaire avec un seul champ mais avoir pour cle primaire la combinaison unique de ses proprietes, ca veut dire que dans la table "possede" ou on a normalement "X possede n produits de type Y", on va se retrouver, puisqu'on n'a pas de cle primaire a un seul champ pour les produits, avec dans la table:
"X possede n produits dont les caracteristiques sont A1, B4, C12, D2, E126, etc..."
 
C'est clairement assez absurde.
 
Si tu ajoutes derriere des trucs comme une table "Z a la technologie pour transformer n1 produits Y1 et n2 produits Y2 en n3 produits Y3", qui se transforme si on n'a pas une cle primaire en une monstrueuse et ridicule table contenant comme champs la cle primaire d'une personne, 3 entiers (les quantites d'input et d'output) et 3FOIS l'ensemble de tous les champs caracteristiques des produits, ca commence a devenir n'importe quoi).
 
Donc je ne sais pas ce qu'il faut faire si comme tu dis je dois en rester avec des produits sans cle primaire a champ unique.
 
D'apres moi, il FAUT une cle a champ unique, sinon c'est un bordel innommable.
Mais comme je ne connais pas le langage et n'ai que la logique pour me guider, j'ai peut-etre completement tort

 
oula oula oula  
 
Bon je persiste et je signe, ce qui te limite ça n'est pas le langage SQL (sinon tu me parlerais de syntaxe), c'est bien la logique pour construire une base de données proprement.
 
Je ne vois absolument pas l'intérêt de construire une table par Produit ! Un produit, c'est un objet à part entière avec des caractéristiques, un numéro, ... et un TYPE.
Donc tu rajoutes tout simplement le type dans ta table des produits !
Comme on suppose que le type peut être assez complexe (avec des infos multiples comme un libellé, une description, une personne à contacter ou que sais-je), on enregistre les infos correspondantes dans une table à part qu'on appelle type_produit. Si l'information est simple (juste un champs), on l'ajoute dans notre table PRODUIT et on met une contrainte pour s'assurer que les valeurs qu'on y met sont bonnes (on interdit d'inscrire TARTAMPION dans le type par exemple).
 
Ensuite, pour les personnes je suppose qu'un produit peut être possédé par plusieurs personnes et qu'une personne peut posséder plusieurs produits (d'où la table intermédiaire). Au final ça me donne ce schéma :
 

 
(Les champs en gras sont des clés primaires)
 
C'est plus clair là ?
 
 
 

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:

 
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.

Oui, je comprends ton problème.
 
Je n'ai jamais dit que ce que je te disait pour identifier un enregistrement de manière unique avec un "couplage" de champs pour la clé primaire concernait toutes les tables !
 
En fait cela ne concerne que les tables intermédiaires ! Pas les objets de base du genre "Produit" ou "Type_Produit". Il te manque de toute évidence des notions en conceptions de base de données. Je te conseille de te documenter sur la méthode d'analyse Merise. Il faut faire abstration des champs que tu mets dans les tables, pour cela on utilise un modèle entité-association.
 
Sur cette page http://www.commentcamarche.net/merise/mcd.php3, on t'explique comment organiser ton modèle sous forme de classes et de relations. C'est la figure hexagonale au milieu à laquelle tu dois t'intéresser et c'est elle qui te pose problème ! Pour les classes, aucun problème, je pense que tu as compris qu'on met en général une clé primaire en auto_increment. Ca je ne le conteste pas, on fait toujours comme ça et la table Produit en est le parfait exemple ! La différence est au niveau des relations. La table Habite ne représente pas un objet en soit, elle permet de répondre au problème "une personne habite a X adresses et une adresse est habitée par X personnes". On a donc une double relation (0,n), (là il faut au moins lire la page dont j'ai donné le lien sinon tu ne peux pas comprendre), et cette relation se traduit par une table avec une double clé primaire. C'est pour cette raison qu'il est INUTILE de mettre une clé primaire unique en auto_inc sur cette table.
 
Enfin, pour ta table "Possede", il est inutile d'inclure la quantité dans la clé primaire puisque tu peux identifier de manière unique un enregistrement avec le simple couple (produit,personne).
 
Essaye de regarder les infos sur la méthode Merise depuis le début http://www.commentcamarche.net/merise/concintro.php3. J'espère que ça t'éclairera. Sinon il faudra essayer de faire le modèle entité-association de ta base de donnée et j'espère que tu comprendras.

Bon, c'est gentil de me dire que je manque de notions, mais depuis le premier post je dis que ce qu'il faut pour mon cas c'est une cle primaire d'un seul champ, et c'est la conclusion, donc ca ira.
Et on en revient donc au premier point, a savoir que pour assurer l'unicite, un petit unique index est donc la solution, a moins qu'il n'y ait encore autre chose.
 
La table habite a bien evidemment une relation 1..n (et pas 0..n d'ailleurs) avec les personnes et les adresses.
Et je suis d'accordavec le fait que pour la table de jointure (quel est le mot juste?), on peut utiliser une cle a deux champs. Mais mon probleme etait pour la table produit ou j'avais cru comprendre que tu preconisais pareil, puisque tu n'avais pas fait de distinction (mais il faut dire que je n'en avais pas specifiquement demande ).
 
Pour commentcamarche, ca va aller, mon modele est termine avec DBDesigner4, et j'ai bien toutes les relations comme il faut, le seul point qui posait probleme n'etait certainement pas dans quel sens se font les relations etc, mais uniquement comment imposer l'unicite sans multiplier les champs composant la cle primaire. Et s'affranchir des champs, ok, il faut penser en termes de cles, mais bon, justmeent, la il s'agissait de pouvoir penser en termes de cles sans lourdeur immonde, et donc de ne pas avoir de cle a plusieurs champs hors des tables de "jointure".
 
Bon, cela dit tout cela est ma faute, il me manque (enfin, manquait, un peu moins maintenant) tout le vocabulaire (mais meme si je ne savais pas quel mot employer, mon modele etait fait avec toutes les relations, etc).
 
Bon, merci en tt cas, et a part ca il est vrai que je manque de notions, mais pas autant que tu le crois quand meme, en tout cas sur la conception)

 
Bon j'abandonne, si c'est ça la conclusion à laquelle tu arrives libre à toi... J'ai passé au moins 4 posts à t'expliquer que cette solution n'était pas satisfaisante et qu'une double clé était beaucoup mieux ... (menfin cette solution marche)

Eh!!!
Tu me lis?
 
Je t'ai encore une fois dit que OUI, pour la table de jointure, exactement comme TU le dis, c'est effectivement la solution, mais que depuis le debut,mon probleme est sur la table produit ou equivalent.
 
Il me semble que je l'ai encore dit clairement dans le post precedent.
 
Simplement comme tu pars du principe que je dis n'importe quoi, forcement tu ne lis pas, et tu ne sais meme pas de quoi je parle.
 
On le refait:
Toi:

 
Moi:

 
 
Toi:

 
Il ne me semble pas que ton dernier post soit justifie... Tu me dis, et c'est ce que je demandais depuis le debut (tout en m'exprimant tres mal et en ne detaillant que peu a peu, il est vrai), que je ne dois PAS utiliser de cle double pour "produit" et autres, je te repond que je suis d'accord et que c'est ce que je cherchais a clarifier, et ensuite tu viens me dire que tu m'as explique le contraire pendant 4 posts...
Bon, enfin, c'est parce que tu n'as meme pas lu mon post et que tu t'es arrete a la ligne 3.
 
 
Meme si tu ne me lis pas et que tu me prends pour un debile, je te remercie encore une fois de tes instructives admonestations.

Bah écoute je suis désolé mais le prend pas mal. J'aurais jamais pris autant de temps à te répondre si je t'avais pris pour un débile.
 
Je suis désolé mais je lis ton PREMIER post :
 
Imaginons, j'ai ma  
- table Nom avec idNom, Nom
- ma table adresse avec idAdresse, Adresse
- une table habite contenant Nom.idNom, Adresse.idAdresse, et eventuellement (ca fait partie de la question) idhabite.
 
Je veux que plusieurs personnes puissent habiter le meme endroit, qu'une personne puisse avoir plusieurs residences, mais je ne veux pas qu'il y ait plusieurs fois la meme personne a la meme adresse.
 
Que dois-je faire?
Index unique, cle unique, cles secondaires, cle primaire ou pas de cle primaire?
 
Et la réponse que je donne n'est absolument pas:
Pour assurer l'unicite, un petit unique index est donc la solution, a moins qu'il n'y ait encore autre chose.
 
Moi je te répond:
Pour assurer l'unicité de la table Habite, il faut mettre une double clé primaire. Le champs idHabite n'a aucune utilité et ne permet pas de vérifier la cohérence des données.
 
Voilà pourquoi je dis que tu aboutis à la mauvaise conclusion.