Discussion :

[gb-ch]

Bonjour,

Comment ajouter une clé étrangère sur une colonne d'une table "parent" (ou "mère" ;o) qui ferait référence à la clé primaire d'une table "enfant" (ou "fille" ;o) mais alors que la table "parent" n'est pas vide?

Exemple,

J'ai une table "enfant"

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
CREATE TABLE `categorie` (
  `id` int(11) NOT NULL auto_increment,
  `label` varchar(255) collate utf8_unicode_ci NOT NULL
  PRIMARY KEY  (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci AUTO_INCREMENT=1 ;

puis une table "parent"

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
CREATE TABLE `objets` (
  `id` int(11) NOT NULL auto_increment,
  `categorieId` int(11) NOT NULL
  `titreFr` varchar(255) collate utf8_unicode_ci NOT NULL,
  `titreEn` varchar(255) collate utf8_unicode_ci default NULL
  `descriptionFr` text collate utf8_unicode_ci,
  `descriptionEn` text collate utf8_unicode_ci
  PRIMARY KEY  (`id`),
  KEY `categorieId` (`categorieId`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci AUTO_INCREMENT=230 ;

C'est donc cette deuxième table qui n'est pas vide.

OK, je peux copier ma table `objets` (structure et données) puis la vider et puis ce sera possible d'ajouter la relation via un

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
ALTER TABLE `objets` ADD FOREIGN KEY ( `categorieId` ) 
REFERENCES `mydatabase`.`categorie` ( `id` );

et ceci sans obtenir une erreur 1452 de type "Cannot add or update a child row: a foreign key constraint fails..."

Mais, ensuite, comment repeupler la table "parent" qui n'était pas vide au début?

[nounetmasque]

Il se peut que je n'ai rien compris... En tout cas je ne pense que ça soit possible et surtout je ne vois pas l'utilité de mettre des clés étrangères entre deux tables si tu ne renseignes pas la table mère. En effet, les clés étrangères permettent de respecter des contraintes entre les données or ta technique revient à passer outre ces contraintes...

[gb-ch]

J'ai dû mal m'exprimer... Posons les bases...

Celle que j'apelle table mère c'est celui qui a la clé étangère et celle que j'apelle table fille c'est la table liée. En d'autres termes, la valeur de ma colonne clé étrangère dans la table mère = valeur de ma clé primaire dans la table fille.

Dans mon exemple, 'objets' est la table mère et 'categorie' la table fille. La colonne 'categorie_id' de ma table mère 'objets' fait référence à la clé primaire 'id' de ma table 'categorie' fille.

Voici l'explication de ma question...

J'ai à la base que la table 'objets' et celle-ci n'est pas vide. Mais la colonne 'categorie_id' était à NULL jusqu'à présents pour toutes les lignes. Maintenant, j'aimerais créer ma table 'categorie' et j'aimerais créer cette relation. Impossible! Je dois d'abord vider la table et ensuite je peux créer ma relation. Mais ensuite comment repeupler ma table 'objets' sans abotenir une erreur 1452 de type "Cannot add or update a child row: a foreign key constraint fails..."?

Merci...

[Antoun]

sur objets, enlève la déclaration de CategorieID comme NOT NULL.

[gb-ch]

OK, merci!

[Gluups]

Bonjour,

Je crois que ce que tu cherches est là :
https://blog.developpez.com/elsuket/...des_donne_2008

J'ai déjà créé avec ça sous SSMS pour SQL Express 2008 R2, des scripts avec les instructions INSERT INTO ... pour recréer les tables, afin de créer la méthode Seed utile pour les migrations sous MVC.

Malheureusement j'ai l'impression qu'avec SQL Express 2014 on n'a pas toutes les options, ça n'enregistre que la structure de la table. Ou alors il y a quelque chose que je n'ai pas vu ...

Dans le menu tâches tu as aussi une commande exporter, qui te permet d'obtenir les données dans un support externe. Normalement on devrait pouvoir écrire dans un fichier texte, chez moi ça a coincé aussi, mais je l'ai obtenu sans problème dans un fichier Excel (bien qu'il y ait eu une table d'une autre base avec, enfin quand il n'y a que ça on efface la feuille ...)

Bien sûr, avec cette méthode-ci, ça t'oblige à mettre les mains dans le cambouis après, si tu veux un script SQL.

Ou alors tu utilises la commande d'import, dans le même menu. Celle-là je ne l'ai pas testée.

[CinePhil]

J'ose espérer que depuis 11 ans il a trouvé la solution !

En plus, vous répondez selon Microsoft SQL Server alors que vous êtes dans le forum MySQL !

Bref ! Déterrer les discussions n'est pas souhaité.

[Gluups]

ça voudrait dire que jamais plus, personne n'aura besoin de sauvegarder une table avant de modifier sa structure ?

Très, très étrange.

--
Ah oui l'erreur de plateforme, en revanche, désolé.

[isabelle.letrong]

ça voudrait dire que jamais plus, personne n'aura besoin de sauvegarder une table avant de modifier sa structure ?

Je me permets une remarque, même si la discussion est fermée : c'est juste que, dans le cas présent, cela ne servait à rien de sauvegarder la table pour la recharger après, puisque le problème était la clause NOT NULL concernant la colonne 'objets.categorieID' qui empêchait l'opération. L'opération de rechargement de la table objets après avoir ajouter la colonne objets.categorieID, aurait de toutes les manières échoué !

Un petit retour sur la conception de cette évolution :

Hypothèse N°1 : vous connaissez la catégorie de chacun des objets et vous souhaitez qu'à terme objets.categorieID ait l'attribut NOT NULL

Après avoir fait l'upload de la nouvelle table 'categorie' (au passage je vous conseille de mettre les noms de table soit tous au pluriel soit tous au singulier), vous ajoutez la colonne objets.categorieID (DEFAULT NULL), puis un magnifique UPDATE ensembliste permettra de mettre à jour cette colonne. Vous pourrez alors passer l'attribut de la colonne en 'NOT NULL'.

Hypothèse N°2 : vous ne connaissez pas la categorie de chacun des objets et objets.categorieID ne pourra manifestement pas avoir l'attribut NOT NULL

Dans ce cas, le bon réflexe est de ne pas créer de nouvelle colonne dans 'objets' mais de créer une troisième table 'objets_categories' comprenant 2 colonnes respectivement foreign key de 'categories' et 'objets' et dont la clé primaire est constituée par ces 2 colonnes.
Si dans un souci de simplicité apparente vous vous contentez d'ajouter une colonne objets.categorieID dans objets avec l'attribut 'DEFAULT NULL', vous devrez vous encombrer pour toujours de la gestion du NULL concernant cette colonne (oui, rappelons-nous que NULL n'est pas une valeur avec toutes les conséquences qui s'en suivent sur l'approche ensembliste...)

[Artemus24]

Salut à tous.

Détérer un sujet vient de 11 ans (19/08/2007) n'a aucun intérêt !

Comment ajouter une clé étrangère sur une colonne d'une table "parent" (ou "mère" ;o) qui ferait référence à la clé primaire d'une table "enfant" (ou "fille" ;o) mais alors que la table "parent" n'est pas vide?

Il y a une inversion entre la notion de table mère et de table fille dans ces explications.

C'est la table fille qui possède la clef étrangère, et cette clef étrangère va pointer sur la table mère qui possède une clef primaire.
De plus, pour que la déclarative de la clef étrangère fonctionne, il faut que les deux types soient identiques.

Pour la table mère (categorie) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

`id` int(11) NOT NULL auto_increment,

pour la table fille (objets) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

`categorieId` int(11) NOT NULL

Et voici la déclarative à mettre dans la table fille (objets) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
alter table `objets` add
  CONSTRAINT `FK_CATEGORIE` FOREIGN KEY (`categorieId`) REFERENCES `categorie` (`id`) ON DELETE CASCADE ON UPDATE CASCADE

Où se trouve le problème ?

mais alors que la table "parent" n'est pas vide?

Comme gb_ch a inversé la notion des tables mère et de fille, la table fille (objets) n'est pas vide.

Comme le dit Isabelle letrong, nous avons deux cas.
Sauf que je ne présente pas ses deux cas de la même façon qu'elle :
(1)--> toutes les catégories présentes dans la table fille sont aussi présentes dans la table mère.
(2)--> toutes les catégories présentes dans la table fille ne sont pas présentes dans la table mère.

En fait, je vois un trois cas, qui est :
(3)--> dans la table fille, la clef étrangère a été marqué à null pour certaine ligne.

La réponse d'Antoun :

sur objets, enlève la déclaration de CategorieID comme NOT NULL.

concerne justement le troisième cas.

D'où ma question : "pourquoi la clef étrangère pour certaines lignes à été marqué à NULL ?"
Ceci est contestable, mais comme ce choix a été fait, on ne va pas revenir dessus.

La bonne façon de faire est le cas (1). Pourquoi ?
Parce qu'il n'y a aucun intérêt à utiliser une clef étrangère, c'est-à-dire rattacher une ligne fille à une ligne mère si le lien ne se fait pas (à NULL).
C'est un problème d'intégrité des données, qui est dû à un problème dans la modélisation des données.

@+