Discussion :

[lexsteens]

Bonjour,

je dois créer une application multilingue, permettant l'ajout de nouveaux messages textuels en temps réelle dans différentes langues, qui peuvent elles aussi être ajoutées au cours de la vie de l'application.

Est-il préférable de créer
- une table par langue
- ou une seule table contenant tous les messages de toutes les langues, avec un index sur [langue, num_message]
?

Autre contrainte: l'application sera client-serveur, et il doit être possible de charger les messages de certaines langues sur le client, mais pas forcément toutes les langues. Tous les messages seront par contre présents sur le serveur.

Compte tenu de toutes ces informations, je me pose des question sur les points suivants:

- la performance, cet index sur 2 clef sera-t-il aussi efficace qu'un index sur une clef, la jointure devant alors prendre en compte la table en question;
- l'évolutivité, pourrait-il se poser des problème dans une des deux solutions auxquels je n'ai pas pensé?
- la simplicité d'utilisation et la clarté des requêtes
- ...

[Edit:]
- les collations, la méthode avec différentes tables permettrait d'avoir des collations différentes par langue (tout message sera de toute façon stocké en UTF quelque soit la langue), ceci est peut-être un des points les plus important et je ne connais rien sur le sujet, je viens seulement d'apprendre que ça existait. Quels problèmes pourraient survenir? Sachant que l'application devra gérer des langues aussi dissemblables que le français et le chinois, avec leurs problèmes propres si j'en crois ce que je lis. Quel impact chaque méthode aura-t-elle sur 1) la recherche 2) le tri.

Y aurait-il d'autres avantages et inconvénients à chaque solution?

Merci d'avance.

[SQLpro]

ou une seule table contenant tous les messages de toutes les langues, avec un index sur [langue, num_message]

Sans hésitation oui, et bien entendu avec une table des langues.

...les collations, la méthode avec différentes tables permettrait d'avoir des collations différentes par langue (tout message sera de toute façon stocké en UTF quelque soit la langue),

Ne vous focalisez pas sur les pages de code, cela n'a pas d'importance en matière de SGBDR. En revanche vous devez utiliser de l'UNICODE (donc NVARCHAR ou NCHAR) et piloter la collation à la volée en sortie du SELECT.
N'oubliea pas dans votre table des langue de prévoir une colonne pour y stocker la collation relative à la langue.

A +

[lexsteens]

j'étais justement en train de lire certains de vos articles sur le SQL, dont celui sur l'optimisation, dans lequel vous dites qu'il est préférable d'utiliser des jointures sur une seule colonne. Le cas des collations étant réglé (si tous les SGDBs le gèrent...), reste celui de la performance. Il est tout de même préférable selon vous d'utiliser une seule table?

Sans hésitation oui, et bien entendu avec une table des langues.

Pourriez-vous préciser les avantages et inconvénients des 2 méthodes, je suppose que vous avez déjà du avoir cette expérience.

En revanche vous devez utiliser de l'UNICODE (donc NVARCHAR ou NCHAR)

Je ne comprends pas, le fait de déclarer la table ou la colonne en unicode ne suffit pas? Si la table est déclarée en unicode mais qu'une colonne est varchar il la considère comme non unicode? Pourriez-vous m'éclairer ou m'indiquer un document traitant de ce sujet pour les base de données?

Sur le même sujet, est-il intéressant de limiter la taille des varchars (et donc de créer plusieurs tables avec des messages de taille maximum différentes?). Dans tout ce que j'ai lu il semblerait que non, à part pour imposer des contraintes fonctionnelles sur les données. Vous confirmez? S'il y a beaucoup d'insertion/suppression, cela ne risque-t-il pas de fragmenter la base de donnée à outrance?

Dernière question: y'a-t-il des SGBDR plus adaptées au multilinguisme que d'autres?

[SQLpro]

Pourriez-vous préciser les avantages et inconvénients des 2 méthodes, je suppose que vous avez déjà du avoir cette expérience.

Désolé je n'aurais pas le temps de vous faire un cours de modélisation de donées et ses conséquences en terme de performances. Mais en revanche, vous pouvez demander une consultation via ma sté SQL spot, www.sqlspot.com.

Si la table est déclarée en unicode mais qu'une colonne est varchar

Une table ne se déclare pas en unicode. Une colonne est pourvue d'un type de données. CHAR et VARCHAR reposent sur un codage ASCII (donc forcément une page de code) et NCHAR et NVARCHAR sur le codage unicode.
Lisez ce que j'ai écrit à ce sujet : http://sqlpro.developpez.com/cours/s...age=partie1#L4.
La collation règle les problèmes de correspondances entre majuscule minuscules, et caractères diacritiques ainsi que l'ordre de tri des caractères.

Formez vous à SQL et aux concepts de bases de données relationnelles. Mes livres comme mon site web, peuvent vous y aider !

A +