Discussion :

[berthos]

Bonjour

J'ai créé plusieurs foreign keys dans ma base et dans PhpMyAdmin, l'affichage de la liste déroulante de choix semble réagir de manière aléatoire.
Comment peut-on correctement définir une foreign keys dans PhpMyAdmin pour qu'il affiche la bonne colonne (en plus de l'Id recherché).

Pour être concret voici une table dans laquelle j'ai 2 champs liés à d'autres tables



Le champ ElementTable_Id contient l'Id de la table de l'élément et pointe vers le champ Id de la table Table (qui contient le champ Titre pour la table).
Du coup il s'affiche ElementTable_Id - [Titre de la Table]

Par contre ça ne marche pas pour le champ ArticleType_Id qui pointe vers l'Id de la table Type (qui contient le champ Titre pour le Type)

Les contraintes FK sont les suivantes :

Code :

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

1
2
3
ALTER TABLE `articles_elements`
  ADD CONSTRAINT `fk_articles_elements_types_01` FOREIGN KEY (`ArticleType_Id`) REFERENCES `types` (`Id`),
  ADD CONSTRAINT `fk_articleselements_tables_01` FOREIGN KEY (`ElementTable_Id`) REFERENCES `tables` (`Id`);

Auriez-vous une idée pour m'aider ?

Apache : 2.4.39
OpenSSL : 1.0.2r
PHP : 7.3.5
phpMyAdmin : 4.8.3

[CinePhil]

Le code SQL des contraintes semble correct. Qu'est-ce qui ne fonctionne pas ? Vous avez un message d'erreur ?

Choses à vérifier :
- la table référencée dans la contrainte doit déjà exister ;
- la colonne référencée dans la contrainte doit déjà exister et être du même type que la colonne portant la clé étrangère ;
- s'il y a déjà des valeurs dans la table référencée et dans la table porteuse de la clé étrangère, il faut que toutes les valeurs de la colonne clé étrangère existent déjà dans la table.colonne référencée.

[berthos]

Bonsoir,

Pas de message d'erreur. Mais les 2 FK ne réagissent pas pareil au sein d'une même table :
Ici la liste affiche l'Id et le Titre : ce qui est très bien pour moi

Ici la liste affiche l'Id et un autre Id de la table cible : pas très pratique


Les tables référencées existent bien cf schéma ci-dessous (fait avec Workbench) :


Les champs sont tous des INT(11)

Les valeurs recherchées existent bien dans la table cible.

[CinePhil]

Ce que phpMyAdmin affiche comme possibilités pour les colonnes clés étrangères sont les valeurs contenues dans les colonnes munies d'une contrainte d'unicité. C'est évidemment le cas de la clé primaire.

Dans le premier cas, je suppose que la colonne tables.Titre doit être munie d'un index UNIQUE, ce qui la fait apparaître dans la liste de choix.
Dans le second, avez-vous un index UNIQUE dans la table types ?

phpMyAdmin est un outil pour administrer plus facilement une BDD qu'en ligne de commande mais ce n'est pas une interface pratique pour gérer les données. Il faut programmer un logiciel qui utilise la BDD avec une interface graphique pour présenter agréablement et pratiquement les données.

Au passage...
1) Vous ne devriez pas appeler vos tables au pluriel. Une table est issue d'une entité type du modèle conceptuel de données, laquelle est issue d'une règle de gestion des données qui explique ce qui se passe pour UNE table, UN article... Le pluriel peut créer des confusions dans la compréhension du schéma.

2) Il y a une boucle dans votre schéma qui peut causer des incohérences de données.
Un élément d'article peut être associé à un type qui est associé à une table qui n'est pas celle de l'élément. Normal ?

Si vous voulez de l'aide pour modéliser correctement votre BDD, c'est par là.

[berthos]

Bonjour,

Merci pour votre réponse qui est comme toujours pleine de bon sens.

Pour les tables au pluriel, c'est en cours de modification.
Pour le problème de contradiction des champs table, je suis en train de remodeler les données.
Pour le champ unique, en fait j'avais un champ PRIMARY (l'Id) et un index UNIQUE Titre + ElementTable_Id mais je vais changer cela parce qu'en dehors d'être visuellement pratique cela ne sert strictement à rien à part d'arriver à une incohérence.

Merci à vous

[CinePhil]

Pour le champ unique, en fait j'avais un champ PRIMARY (l'Id) et un index UNIQUE Titre + ElementTable_Id mais je vais changer cela parce qu'en dehors d'être visuellement pratique cela ne sert strictement à rien à part d'arriver à une incohérence.

La contrainte d'unicité, matérialisée chez MySQL/MariaDB par un index de type UNIQUE, signifie que toutes les valeurs de la colonne concernée (ou du groupe de colonnes concernées) doivent être uniques. À vous de voir si c'est le cas ou pas.

Exemple avec les départements français :
tr_departement_dpt (dpt_id, dpt_numero, dpt_nom)
La clé primaire est ici la colonne dpt_id, de type entier mais il est évident que la colonne dpt_numero, de type CHAR(3) devra être munie d'un index UNIQUE.