Comme l'indique le sujet de mon mail, je suis en SID donc ma version de MySQL est la 4.0.17-2.
Lorsque je fais un mysqldump, je vois bien le type de table � savoir les MyISAM, il me faut donc cr�er une table de type InnoDB. J'ai donc modifi� mon script de cr�ation de la base: CREATE TABLE Cmd_gcos ( Num_Commande INT(255) NOT NULL AUTO_INCREMENT, Nom_Commande VARCHAR(100) NOT NULL, Description TEXT NOT NULL, Nom_Type VARCHAR(30), Nom_Periode VARCHAR(30), PRIMARY KEY (Num_Commande), CONSTRAINT Periode FOREIGN KEY (Nom_Periode) REFERENCES Periodicite (Nom_Periode), CONSTRAINT Type FOREIGN KEY (Nom_Type) REFERENCES Type (Nom_Type) ) TYPE=InnoDB ; Ensuite j'ai fait un DESC de la table et le flag FOREIGN KEY n'apparait toujours pas. Il me reste � v�rifier si les Foreign key sont bien prises en compte en essayant pas exemple de rentrer des donn�es incoh�rentes dans les tables. Je vous tiens au courant =-) Merci Laurent Oliva Le mer 18/02/2004 � 19:07, Nicolas Rueff a �crit : > Dans MySQL, seules les tables de type InnoDB acceptent les FK, me > semble-t-il. En tout cas le type par d�faut (MyISAM) ne les prend pas en > compte: > > � En MySQL version 3.23.44 et plus r�centes, les tables InnoDB > supportent les v�rifications d'int�grit� r�f�rentielles. Pour les > autres types de tables, le serveur mySQL accepte la syntaxe FOREIGN KEY > dans la commande CREATE TABLE , mais ne la prend pas en compte. � > > Toujours issu de la doc de MySQL: > > � Voici des avantages aux contraintes de cl�s �trang�res : > * En supposant que les relations soient proprement con�ues, les cl�s > �trang�res rendent plus difficile pour un programmeur d'ins�rer des > valeurs incoh�rentes dans la base. > * L'utilisation des modifications et effacement en cascade simplifie > le code du client. > * Les r�gles de cl�s �trang�res proprement con�ues aident � la > documentation des relations entre les tables. > > Inconv�nients : > * Les erreurs, qui sont faciles � faire durant la conception des > relations, peuvent causer des probl�mes graves : par exemple, des r�gles > de contrainte circulaires, ou des combinaisons erron�es d'effacement. > * Une application correctement �crite s'assure d'elle-m�me de > l'int�grit� r�f�rentielle des donn�es avant d'ex�cuter une requ�te. De > ce fait, les v�rifications suppl�mentaires de la base sont inutiles et > r�duisent les performances de l'application. > * Il n'est pas rare pour un administrateur de bases de donn�es de > faire une topologie complexe des relations entre tables qui rendent tr�s > complexe, voire impossible de restaurer des tables. � > > Point de vue d'un gars ayant bricol� pas mal de donn�es > (bioinformatique, suivi de prod, base de produits clients, donn�es > issues de mesures ...) en 4 ans de mysql: mysql est fait pour bourrer, > et bourre plus si on s'abstient de lui mettre des b�tons dans les roues > styles"cl�s �trang�res". Si ton appli est bien cod�e, pas besoin d'en > utiliser, mais si tu en as vraiment besoin, tourne-toi plut�t vers > postgres. >
