Mysql.._[JOINTURE - PRIMARY KEY - UNIQUE - INDEX ]

WRInaute accro
Bonjour,

j'ai une table de jointure, qui est donc composé de deux clés étrangères.
Elle ne contient donc aucun index, et je souhaiterai savoir si dans mysql il est possible de lui indiquer qu'il s'agit d'une table de jointure ?

Merci
 
WRInaute passionné
Re: Mysql, une table de jointure...

thierry8 a dit:
Bonjour,

j'ai une table de jointure, qui est donc composé de deux clés étrangères.
Elle ne contient donc aucun index, et je souhaiterai savoir si dans mysql il est possible de lui indiquer qu'il s'agit d'une table de jointure ?
Merci

Pourquoi elle ne contient aucun index ?
au contraire tu as tout intérêt à indexer ces 2 champs pour optimiser tes requêtes SQL.
Les contraintes de clés étrangères existent dans MySQl 5 ( et peut-être dans MySQl 4, à faire confirmer ).
 
WRInaute accro
mais je ne peux indexer deux id de ma table (id_table1 liée à id_table2), car avec un index cela signifie que l'id est unique or ce n'est pas le cas je peux retrouver plusieurs fois un id !
 
WRInaute passionné
Code:
ALTER TABLE `table_jointure` ADD INDEX `FK_table1` ( `IDTable1` ); 
ALTER TABLE `table_jointure` ADD INDEX `FK_table2` ( `IDTable2` );

ne pas confondre index et clé primaire.

et si ta version de mysql supporte les contraintes de clé étrangères :
Code:
[CONSTRAINT symbol] FOREIGN KEY [id] (index_col_name, ...)
    REFERENCES tbl_name (index_col_name, ...)
    [ON DELETE {RESTRICT | CASCADE | SET NULL | NO ACTION}]
    [ON UPDATE {RESTRICT | CASCADE | SET NULL | NO ACTION}]
 
WRInaute discret
tu as qu'à indexer le couple d'ids comme unique.

table A: id,pif,paf
tableB :id,pof,pum

tableJonction idA,idB (unique)
idA1,idB (unique)

.
.
.
 
WRInaute passionné
thierry8 a dit:
humm...comment faire avec phpmyadmin ?

tu clique sur la structure de ta table :
- liste des clés et index présents
Créer une clef sur n colonne(s) -> Exécuter
- renseigner le formulaire.

sinon tu peux aussi essayer ça directement en sql :
Code:
ALTER TABLE `table_jointure` ADD INDEX `FK_table1` ( `IDTable1` );
ALTER TABLE `table_jointure` ADD INDEX `FK_table2` ( `IDTable2` );
ALTER TABLE `table_jointure` ADD UNIQUE `PK_ID1_ID2` ( `IDTable1` , `IDTable2` );

oerso, je suis partisant de la mise en place des trois index :
- les update et les delete seront un peu moins performant
- tu gagneras bc sur les select.
 
WRInaute discret
si jamais tu peux te connecter directement sur ta bss, tu peux tester mysql control center.

Cette interface est bien faite et puissante.
 
WRInaute discret
pour la taille, cela de permet d'ajuster la memoire alloue pour une variable.


En unique sur les 2 clefs, cela te certifie que tu n'auras pas 2 fois le meme couple idA,idB.

le fait d'etre unique indexe par la meme occasion il me semble.
 
WRInaute accro
euh...si je ne me trompe pas c'est l'inverse, le fait d'être indexé, la clé est unique...

En revanche dans mon cas, même les deux id ne peuvent être unique!

Je peux très bien avoir deux fois cela:
id1 = 1
id2 = 1
 
WRInaute discret
le pb n'est pas d'avoir id1=1,id2=1

mais d'avoir id1=1,id2=1
et
id1=1,id2=1


c'est le couple id1,id2 qui doit etre unique.

ps: indexe ne force pas l'unicité...à mon avis, voir la doc de mysql pour plus de renseignement
 
WRInaute accro
et oui je suis dans ce cas !
id1=1,id2=1 ET id1=1,id2=1 (cas possible)

est-il possible dans ce cas d'indexer quelque chose pour accèlerer les requetes ?
 
WRInaute passionné
thierry8 a dit:
euh...si je ne me trompe pas c'est l'inverse, le fait d'être indexé, la clé est unique...
non, c'est chantra qui a raison. c'est l'inverse.

thierry8 a dit:
En revanche dans mon cas, même les deux id ne peuvent être unique!

Je peux très bien avoir deux fois cela:
id1 = 1
id2 = 1

là j'ai perdu le fil.
pourquoi tu peux avoir ça ? c'est pas normal.
Tu as un pb dans la conception de ta base.
Tu peux poster les structures de tes 3 tables ?
 
WRInaute accro
en gros:

TABLE 1: pages
id
url

TABLE 2: elements_ds_pages
id_page
id_elmt
typ_elmt

TABLE 3: divers elements
id
....


Bien entendue c'est vraiment grossièrement !
Il faut considérer que les tables ne peuvent qu'être ainsi !
Il y a encore pas mal de champs qui me permettent de dire cela !
(je suis certain de ma structure, cependant je l'ai mis pour que vous puissiez constaté que la TABLE 2 peut effectivement avoir id_page=1+id_elmt=1 ET id_page=1+id_elmt=1 du fait que le troisième champ "typ_elmt" permet de définir de quel element il s'agit)
 
WRInaute passionné
thierry8 a dit:
TABLE 2: elements_ds_pages
id_page
id_elmt
typ_elmt


Bien entendue c'est vraiment grossièrement !
Il faut considérer que les tables ne peuvent qu'être ainsi !
Il y a encore pas mal de champs qui me permettent de dire cela !
(je suis certain de ma structure, cependant je l'ai mis pour que vous puissiez constaté que la TABLE 2 peut effectivement avoir id_page=1+id_elmt=1 ET id_page=1+id_elmt=1 du fait que le troisième champ "typ_elmt" permet de définir de quel element il s'agit)


Je suppose que tu as +sieurs table correspond auxtype d' éléments :
- des news
- des trucs
- des bibules

=> ta clé primaire c'est : id_page, id_elmt, typ_elmt

typ_elemnt te permet de te joindre à la bonne table, c'est ça ?
 
WRInaute passionné
thierry8 a dit:
et pourquoi ne pas le mettre en index ?
la différence je comprends pas entre les deux ?

Tu n'est pas obligé d'avoir une clé primaire, ou un index unique sur une table.
cela pourrait te permettre d'éviter des erreurs.
Tu insére dans ta table :
id1=1, id2=1, type_elmnt=1
id1=1, id2=1, type_elmnt=1

si tu as une clé primaire ou un index unique sur ces trois champs le 2° insert va échouer.
A toi de savoir si ce cas est possible ou non. A mons avis, non.

Un index : te permet d'optimiser les performances de tes requêtes SELECT.

Unique : est une propriétés supplémentaire d'un index.

Une clé primaire est un type d'index particulier qui identifie de manière unique un enregistrement.

Dans une table tu peux avoir simultanément :
- Une clé primaire ( index unique )
- Plusieurs clés étrangéres ( index non unique )
- Des index multi-colonnes.
- un ou plusieurs index unique.
 
WRInaute accro
J'en reviens au problème et je vous remercie tous de votre aide !
-> En fouillant un peu sur l'installation de EasyPHP, sur la table mysql, j'ai pu m'apercevoir qu'ils mettaient le même style de champ que moi en clé primaire... <-

Donc je fais un petit récap' qui pourra servir à d'autres:
(corrigez moi si je me trompe)

Clé primaire: identifie de manière unique un enregistrement (INDEX + UNIQUE). La différence avec Unique c'est qu'il peut englober plusieurs champs et donc la clé est relative à l'ensemble de ces champs.

Unique: permet de rendre spécifiquement un champ unique, pour éviter les doublons. Par la même occasion un champ unique sera indexé.

Index: permet d'indexer un champ pour améliorer la vitesse des recherches sur ce même champ. En revanche la vitesse d'insertion ou de modification sera diminuée.

J'espère avoir bien résumé !

Merci à tous ceux qui m'ont aidé !

EDIT: J'ai constaté également que sur la base de données mysql (PHPMyAdmin), la table db possède plusieurs champs en PRIMARY KEY, mais que l'un de ces champs est repris en index a part...
Pourquoi donc ? PRIMARY KEY ne remonterait-il pas l'index automatiquement ? (on pourrait donc aussi penser qu'il en est de même pour "unique")
 
WRInaute impliqué
spidetra a dit:
Tu n'est pas obligé d'avoir une clé primaire, ou un index unique sur une table.

C'est la clé primaire qui identifie de manière unique un enregistrement, s'il est impossible de déterminer une clé primaire, il y a une grosse erreur de conception.
C'est une des bases de la théorie des base de données relationnelles ( première forme normale ) après qu'elle soit indiquée ou non au SGBD est une autre chose.

La clé primaire peut être un champs ou une combinaison de plusieurs champs. Elle est de préférence numérique ( entier non signé de préférence ) afin d'optimiser les performances.
 
WRInaute passionné
shrom a dit:
C'est la clé primaire qui identifie de manière unique un enregistrement, s'il est impossible de déterminer une clé primaire, il y a une grosse erreur de conception.
C'est une des bases de la théorie des base de données relationnelles ( première forme normale ) après qu'elle soit indiquée ou non au SGBD est une autre chose.

d'accord à 100% shrom. Je n'ai jamais fait une table sans clè primaire.
C'est tout a fait le sens de mon post.
 
Discussions similaires
Haut