Discussion :

[pascalacsap]

Bonjour,

Je vais poser une question sans doute bête et naïve, mais je n’ai pas trouvé de réponse claire (et je débute, merci d’être indulgent !).

Admettons que j’aie 2 tables :
Termes (id_terme, terme)
Synonymes (id_syn, synonyme)

Les champs id_terme et id_syn sont des INT.
Les champs terme et synonyme sont des VARCHAR.

Etant donné qu’il y a une relation n,n entre les 2 tables, je vais créer une table associative faisant correspondre les ID des 2 tables :
Assoc(id_terme, id_syn)

Jusque là OK.

Et là, tout à coup, je me dis : mais après tout, qu’est-ce qui m’empêche de créer une table associative contenant les termes et les synonymes ? Ce sera peut-être moins performant (un peu, beaucoup, je ne sais pas…), mais en cas de problème, j’y verrais plus clair. Ca donnerait ça : Assoc(terme, synonyme)

Est-ce que c’est vraiment une solution à proscrire totalement (en termes de performances) ou pas forcément ?

Merci pour vos réponses.
Pascal

[SQLpro]

En terme de perf, oui !
2 entiers c'est juste un calcul.
2 chaines de caractères il faut tenir compte de la collation :

• sensibilité à la casse ?
• sensibilité aux accents ?
• sensibilité au kanatypes ?
• sensibilité au pas de casse ?
• tri spécifique à la langue ?

Ceci signifie que l'extra overhead engendré par des chaines de caractères est important et dans certains cas catastrophique car de nature à empêcher l'utilisation des index.

A +

[pascalacsap]

Ok merci pour ta réponse, cela confirme effectivement ce que je supposais.

Mais en fait, ma question porte plus sur le "principe" :
Est-ce que, à ton avis, c'est quelque chose qu'il faut absolument éviter, ou est-ce que, dans certains cas, on se peut se permettre de le faire ?
En l'occurrence, les tables dont je parle auront quelques dizaines, voire quelques centaines d'entrées au maximum.
Est-ce qu'il y a une limite (que l'on pourrait éventuellement déterminer par des tests, au cas par cas) en-dessous de laquelle ce serait acceptable, et au-dessus de laquelle cela aurait vraiment trop d'impact sur les performances ?
Ou est-ce qu'il vaut mieux, PAR PRINCIPE, éviter de faire ce genre de choses ?

Merci encore.
Pascal

En terme de perf, oui !
2 entiers c'est juste un calcul.
2 chaines de caractères il faut tenir compte de la collation :

• sensibilité à la casse ?
• sensibilité aux accents ?
• sensibilité au kanatypes ?
• sensibilité au pas de casse ?
• tri spécifique à la langue ?

Ceci signifie que l'extra overhead engendré par des chaines de caractères est important et dans certains cas catastrophique car de nature à empêcher l'utilisation des index.

A +

[SQLpro]

Le nombre de ligne d'une table est une chose. La cardinalité d'une jointure en est une autre. Une table de 1000 ligne c'est pas grand chose. Mais une jointure sur 1000 lignes d'un côté et 1000 lignes de l'autre, c'est tout de suite 1000000 de lignes à brasser dans le pire des cas. Ce n'est donc pas le nombre de ligne de la table qui compte mais combien au pire de ligne peut-il y avoir dans l'ensemble des jointures de la requête !

Autrement dit, l'utilisation de chaînes de caractères comme clef est Toujours stupide quelque soit le nombre de lignes de la table.

A+

[pascalacsap]

OK, merci pour ta réponse.
Pascal

[Artemus24]

Salut pascal.

Quand tu crées une table, tu dois toujours respecter les formes dites normales. Ceci permet d'obtenir une bonne normalisation de ton modèle et cela pose moins de problèmes.

http://fr.wikipedia.org/wiki/Forme_n...ationnelles%29

Est-ce que c’est vraiment une solution à proscrire totalement (en termes de performances) ou pas forcément ?

Pour la question de performance, tu dois te poser ces deux questions :

1) les tables sont-elles statiques ? J'entends par là, des tables dont le contenu ne bouge jamais. Ou si tu préfères, la volumétrie ne bouge pas.

2) est-ce que la volumétrie est faible ? De l'ordre de quelques centaines de lignes au maximum.
Car pour la table "assoc", qui est le résultat de la cardinalité des deux autres tables, cela ne fait qu'au maximum : 100 X 100 = 10.000 lignes

Si tu réponds oui à ces deux questions, ta solution peut-être envisagée.

Inversement, comme tu ne maîtrises jamais ce qui va se passer dans l'avenir, je préfère que l'on respecte les formes normales. Donc préférer la première solution.

3) une volumétrie qui peut exploser car l'usage de tes deux tables ont changé au cours du temps.

4) de nouvelles fonctionnalités dans ton application, font que la maintenance devient lourde.
Il se peut même que ce choix d'origine, induise de tout réécrire car totalement inadapté à ces nouvelles fonctionnalités.

Personnellement, je préfère la première solution, même pour des tables statiques et de volumétrie faible.

@+