La redondance des données dans une BdD

[Plume]

Bonsoir

J'ai modélisé la base de données de [ Seelies ] et durant celle-ci, j'ai rencontré le cas d'une donnée redondante.

L'image qui suit illustre la situation actuelle & comme je l'ai décidé.


La table concernée pour éviter la redondance est `appartient_signes`. A l'origine, j'avais un attribut `signe` dans la table `Seelies`. Et Sephi m'a dit qu'un sort appartenait aussi à un signe. Et il m'a dit qu'il suffisait de rajouter un attribut `signe` dans la table `Sorts`. Et là, vous conviendrez tous qu'il y a redondance.
Voilà pour la mise en situation.

D'un point de vue relationnel, c'est incorrect, c'est pourquoi j'ai créé une troisième table. Cependant, il y aurait des projets qui nécessite une transgression à cette règle.

J'aurais donc aimer savoir quelles limites donnez vous à cette règle ?
En quoi la redondance peut être préférée ?

~L~

[Loetheri]

Pour moi, la redondance peut se voir utile si ta requête devient complexe. Il s'agit là, bien entendu, d'une vision personnelle. Je préfère avoir des requêtes légères et structurés que des requêtes imbriquées les unes dans les autres et ne pas s'y retrouver.
Je dirais que la redondance est permise dans le cas où il faut remonter à plus d'un ou deux étages pour ré-avoir la même information.

Cependant, il faut savoir qu'il vaut mieux faire une énorme requête que deux grosses requêtes.

PS : Pour ta démonstration avec Seelies, il faut m'excuser mais je suis très visuel. Donc je n'ai pas réellement pu comprendre.

[Plume]

Voilà ce que ça aurait donné si je n'avais pas fait de troisième table.


~L~

[naholyr]

Tout dépend du type de ton champ. En l'occurrence le champ "signe" n'est-il pas un ENUM ?
Dans ce cas personnellement je n'aurais pas fait de table intermédiaire, on s'ajoute une jointure bien inutile pour un champ de type scalaire.

[Plume]

J'me suis carrément craqué >.<

Dans le premier cas, remplacer par

Et le deuxième cas


Les posts ont été édités.
Du coup, j'attends de savoir si vos avis sont les mêmes maintenant que les données sont correctes

~L~

[Loetheri]

Les images n'apparaissent pas chez moi sauf dans le code source de la page -_-'

Sinon je dirai comme naholyr : je n'utiliserais pas ces multiples tables intermédiaires. C'est trop

[Plume]

En admettant qu'il soit possible que d'autres tables fassent référence à la table Signes, vous maintiendriez votre avis ?

~L~

[Zamentur]

Moi non plus je vois pas les images alors je m'appuie sur ce que je lis:

Ben pour moi çà depend de l'utilité derriere si on souhaite par exemple afficher tout ce qui est en lien avec un Signes dans ce cas, il y a plusieurs solution:
- faire une table Signes comme indiqué
- on peut aussi imaginer repertorié toute les tables qui font reference à un signes

Mais si il n'y a que des "mouvements" qui parte d'une table pour obtenir son signe (et non l'inverse comme precedement) dans ce cas je vois pas l'interet de creer une table signes supplementaire. Meme si il ya de multiple table qui y font référence.

Surtout si il s'agit d'un Champs ENUM. C'est vrai que dans le cas d'un champs texte(justifié par exemple par l'ajout de signes par les utilisateur ou par un nombre trop important de signes), j'aurais tendances dans ce cas à faire une table intermediaire id signe Mais si j'ai bien compris la question n'est pas là et il n'y a que très peu de signes...