Erreur 1064 CREATE TABLE avec cle reflexive [Résolu]

[ZuZu]

Bonjour,

la requete suivante provoque une erreur à la création de la clé étrangère. La création de la table seule ne pose pas de problème.

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
CREATE TABLE VERSION (
  ID_VER INTEGER UNSIGNED NOT NULL,
  ID_VER_PREC INTEGER UNSIGNED NOT NULL,
  IndiceVersion Varchar(45) NULL,
  DateCreation DATETIME NOT NULL,
  DateModification DATETIME NULL,
  PRIMARY KEY(ID_VER),
  INDEX FK_VER_PREC(ID_VER_PREC),
  FOREIGN KEY(ID_VER_PREC)
    REFERENCES VERSION(ID_VER)
      ON DELETE RESTRICT
      ON UPDATE CASCADE
)
TYPE=InnoDB;

Si je fais référence à une autre table pour la clé étrangère il n'y a pas d'erreur bien entendu.

Merci d'avance

PHPMyAdmin 2.6.1 & MySQL 4.1.9-max

[jota5450]

slt...

Ce que tu essayes de faire, je crois pas que se soit possible....

Une Foreign key, est par difinition, um champ d´une table, qui fait reference a une cle primaire,ou index unique d´une autre table.

Une Foreign key, qui pointe sur la propre table

[ZuZu]

Bonjour,

c'est normalement possible avec MySQL d'après ce que j'ai lu, mais je n'ai pas trouvé de détails sur les possibilités ou les restrictions quand à l'utilisation de ce type de contrainte.

Ca fonctionne très bien dans d'autres SGBD.

L'intérêt est de s'assurer que dans mon cas ID_VER_PREC est un ID_VER present dans la table.
Si je ne trouve pas comment ca fonctionne avec MySQL je ferais une autre table pour le gérer, mais ce n'est pas la seule dans ce cas.

[qi130]

Je viens de faire un essai concluant en 4.1.1:
1/ passage du script de création de la table sans spécifier la FK
2/

Code :

1
2
3
4
5
6
ALTER TABLE VERSION 
 ADD
  FOREIGN KEY(ID_VER_PREC)
    REFERENCES VERSION (ID_VER)
      ON UPDATE CASCADE
     ON DELETE RESTRICT

bizarrement, après plusieurs tentatives infructueuses, j'ai inséré un espace après VERSION, et

[jota5450]

slt....

il me semble que je me suis tromper

Juste une question:

inserer:

ID_ver, ID_ver_pre, indiceversion

1, 1 , "XPTO"

et apres essayer de suprimer

[qi130]

Clair que dans le contexte exposé, ce n'est pas possible du fait des contraintes.
D'un autre coté, c'est le cas extrême que tu signales... charge à l'applicatif de refuser cette configuration (ce dont je ne doute pas compte-tenu du nom des colonnes )

[ZuZu]

Merci qi130,

effectivement ca fonctionne avec d'autres noms de table, espace ou pas après le nom, mais pas avec VERSION (qui n'est pas un mot clé MySQL) ou il reclame un espace, moralite il vaut mieux toujours le prévoir, mais le code était généré automatiquement par DBDesigner, et sur une autre table ca a tres bien fonctionné donc je ne voyais vraiment pas d'ou venait le problème.

jota5450,
il y a une petite erreur, ID_VER_PREC peut être null bien sur (relation 1-n,0-n)
Effectivement, à l'enregistrement des données je verifierai la condition ID_VER <> ID_VER_PREC.

[jota5450]

slt...

je sais que le topic est ferme, mais je suis reste avec des doutes...

1-La foreign key doit accepter des nulls, sinon on arrive pas a effacer toutes les lignes.
2-La foreing key doit accepter des nulls, sinon on est obliger d´avoir la valeur de la foreign key et la valeur de la key de reference pareille, ca pour le premier insert.
3-Les valeurs de la foreign key et de la key de reference ne doivent pas etre pareilles, sinon on arrive pas a supprimer la ligne.
4-Lors de l´insert ou de l´update, on doit verifier que les valeurs de la key et de la foreign key soit diferentes.

On m´a dis que l´appli ferait ca...

wi, mais...
pour la 1; etre obliger d´accepter des nulls pour pouvoir vider une table..
pour la 2; apres la 1... c´est la moin intriguante...
pour la 3; a cause des references... d´accord.. mais ne pas arrivée a suprimer une ligne qui ne fais reference nulle par d´autre que a elle même...
pour la 4; pour moi la plus ... lors le l´insert/update, l´appli doit verifier que id_ver<>id_ver_pre . bon, si on choissis sur une datagrid le id_ver, ca pose pas de probleme... mais si on veut que le client ecrive le id_ver_pre(un numero) dans un textbox, alors dans ce cas, il faudra tester que id_ver<>id_ver_pre.... on devra savoir le numero qui se suit pour id_ver . Et comment faire ca? a moin que l´appli soit monoposte:
-avec une autre table .. dans ce cas, pourquoi le foreign key sur la propre table?
-avec un lock sur la table

Si quelqun veut bien me donner quelques explications... parce que, je dois mal voir le probleme...

[ZuZu]

Bonjour,

je ne vois pas quel est le problème, d'ailleurs la partie interface de l'application n'est pas l'objet de ce post. Dans mon post précédent, je te précise que oui, ID_VER_PREC peut être nul, et oui, ID_VER et ID_VER_PREC sont différents.
Il n'y a rien de compliqué à cela, la colonne ID_VER_PREC ne sert qu'à enregistrer l'ID de la version précédente, il peut ne pas y en avoir bien sur (ID_VER_PREC = null, ce sera le cas pour tous les nouveaux éléments renseignés), et pour ne pas ecrire n'importe quoi, il suffit de ne proposer en choix pour ID_VER_PREC que les valeurs de ID_VER existantes dans la table évidemment.

Je crois que tu te compliques l'esprit, d'ailleurs je ne comprend même pas où tu veux en venir ni ce qui te pose problème. Peu importe d'ailleurs à quoi sert cette table, le problème posé était un problème de syntaxe et a été résolu, et en sois ce type de clé réflexive n'est pas un problème du tout, IDs null ou pas, egaux ou pas.