Le jeudi 19 f�vrier 2004, Laurent Oliva a �crit...
bonjour,
> Ensuite, j'ai lu dans la doc qu'il fallait cr�er un index pour pouvoir
> exploiter les FOREIGN KEY, j'ai donc modifi� mon script en cons�quence:
Ah ? Dans le sgbd dont je me sers il est sp�cifi�, pour les FK:
If referenced columns are specified that are not the key in the
referencing table, the referenced table must have a UNIQUE definition
whose column names and sequence match those of the referenced columns.
pour une syntaxe:
<referential_constraint_definition> ::=
FOREIGN KEY [<referential_constraint_name>] (<referencing_column>,...)
REFERENCES <referenced_table> [(<referenced_column>,...)]
[<delete_rule>]
> PRIMARY KEY (Num_Periode)
> PRIMARY KEY (Num_Type)
> FOREIGN KEY (Num_Periode) REFERENCES Periodicite(Num_Periode),
> FOREIGN KEY (Num_Type) REFERENCES Type(Num_Type)
Dans ton cas:
Les cl� �trang�res (referencing columns) ne sont pas des cl�s de ta
table (referencing table), mais les 'referenced columns' sont cl�s
primaires des 'referenced tables', donc 'unique'.
Alors c'est � regarder pour InnoDB de plus pr�s, j'ai franchement la
flemme de le faire.
Tu ne devrais pas avoir besoin d'indexer celles-ci, d'autant:
* qu'un index est inutile si la table est peu importante (moins de 1000
enregistrements je crois, �a va d�pendre de ta base)
* qu'il n'est pas utilis� si la requ�te ram�ne plus de 25-30% de donn�es
(�a d�pend du sgbd, et de ta requ�te)
--
jm
