Utiliser des INT ou des VARCHAR pour les relations entre les tables MySQL ?

j'éviterais, et en cas de problème tu fais une requete sur les 3 tables pour y voir clair.

 

Tu brises la logique d'une base de données relationnelle : quand tu dois corriger un mot, il faut aller le corriger dans 2 tables au lieu d'une seule. Avec les années et les tables qui s'ajoutent, ça devient un gros bordel quand il faudra faire des modifs, des transferts, des exportations, etc...

Sinon ça marche, c'est juste un peu plus lent, un index avec des nombres, c'est 1 test par ligne, un index avec des mots, c'est éventuellement 2, 3 ou plus de tests par ligne quand les mots commencent pareil.
L'important est de ne pas oublier les clés primaires, et la clé primaire/index sur les 2 champs de l'association ce que plein de gens oublient.

 

Si je peux me permettre,

En terme de bonnes pratiques, je ferai mon model relationnel comme suit :

termes : id (INT), terme (VARCHAR 255)
synonymes : id (INT), terme_id (INT), synonyme_id (INT)

dans la table "synonymes", le champs "synonyme_id" est une relation polymorphe avec "terme". Parce qu'un synonyme d'un terme, c'est un terme (oui, le synonyme de "bestiole", c'est "animal", mais "animal" est synonyme de "bestiole")

Selon ta structure tu risques d'avoir autant de terme que de synonyme, ça risque donc de gonfler ta BDD inutilement.

Ainsi dans ce modèle relationnelle, un terme à plusieurs synonymes qui sont eux-mêmes des termes !

Après... Les relations c'est mieux avec les ID !

Bisous Bécôts <3 <3

 

non en fait tu as bien deux tables mais pas comme ça.

une première avec des mots et leur id, et une seconde avec des couple d'id "termes" et "synonymes" c'est la même chose tu n'as pas besoins de deux tables faut juste appairer des termes pour avoir des synonymes.

Termes (id_terme, terme)
Couples (id_terme, id_terme_syn)

Ce qui de facto répond a ta question car il serait "stupide" de stocker des couple de termes dans la mesure ou cela rendrait la table de terme totalement inutile.

La ou tu dois te poser une question c'est dans ta table de couples, faut il faire deux enregistrement du style (A,B) et (B,A) (puisque c'est la même chose) Là c'est ta logique applicative qui répondra si c'est plus pratique dans un cas ou l'autre.

 

C'est ce que j'ai dit

 

Oui j'étais en train d'écrire quand tu as posté, j'allais pas non plus effacer pour autant.
Le truc c'est que je faisait une recherche annexe pour voir si il n'était pas possible de mettre une collection d'id dans un champ ce qui aurait évité la table de correspondance, mais rien trouvé de pratique a ce niveau.

 

comme tu préconise au début est une solution mais ce que laisse supposer ta question c'est "quid de la suite". Il faudrait en savoir plus sur la finalité pour mettre en parallèle le fait d'ajouter purement et simplement les éléments exclus a la table des termes quitte a ajouter un champ d'identification portant sur le type si tu as besoin de manipuler les deux listes séparément.

un exemple : "équivoque" est un terme qui a deux synonyme direct dans la table des termes "interlope" et "problématique" (c'est disons un "mot unique") mais il en a aussi deux dans celle des locutions adjectivales : "à double sens", "sous entendu". donc soit je range toutes les expressions dans une même table et j'y ajoute une information de type (locution adjectivale, adverbiales, latines, ... périphrase) soit je crée une table pour chaque type possible de mots ou groupe de mots. Mais dans les deux cas je dois lier avec des couple d'id sachant que si tout est groupé j'aurais la nature du couple via le champ de type de la table de termes et que si tout n'est pas lié (tables distinctes) j'aurais la nature du couple par la table que je consulte.

C'est l'application qui dicte le choix pour des raisons de perfs. A titre d'exemple si je me borne au niveau de la langue française a chercher des synonymes sur des termes simples (42 000 mots) dans un corpus courant j'ai environ 160 000 couples, si j'étends cela au expression (en introduisant les locutions par exemple soit 48 000 expressions) je passe a 450 000 couples. Même si ça reste des ordres de grandeur pas trop violents il peut être utile de prendre en compte la finalité pour décider comment répartir les données

On peut tenir le même propos avec les antonymes au passage ...

 

Il faut te faire une idée précise (presque dès le départ) des requêtes que ton logiciel ou site (ce qui reviens au même) va faire sur ta base de données.
En effet en fonction des cas tu peut être amené a avoir une modèle de données en base très optimisé et pertinent mais qui oblige a des requêtes lourdes en terme de performance. Auquel cas il est parfois intéressant de transgresser par exemple la notion de redondance des données évoqué a juste titre par Rick38 plus haut.
De même si le contenu d'un champ fait que tu dois utiliser des fonctions "compliquées" (genre regex par exemple) sur une requête il est parfois rentable de modifier la structure pour gagner en performance...

Les données c'est une chose il faut aussi penser a leur manipulation pour décider si une façon de procéder est plus rentable qu'une autre quand on considère le résultat final. A ce stade la maintenance doit aussi être prise en compte ... Va elle être plus lourde mais rare ? ou alors inexistante de toute façon ... Voir ingérable si ...

La décision du modèle n'est pas qu'une question de contrainte SQL il faut tout prendre en compte.

A titre d'exemple assez différent mais qui illustre cette contradiction entre fonctionnalité et principes de gestion des données, j'ai un site qui demande pour des raisons de taille plusieurs bases de données. En fonction des pages je dois manipuler des groupes de données différents qui sont rarement sur la même base .... J'ai donc choisi de dupliquer des tables pour faciliter la récupération de données via une requête au lieu de deux connections avec passage de paramètre de façon applicative.
J'y perd sur la maintenance (quand je dois modifier une data c'est sur plusieurs bases) mais j'y gagne énormément en temps de traitement et ça c'est 99% de l'usage.