Re: [SID] MySQL et FOREIGN KEY
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.
>
Reply to: