Discussion :

[Kropernic]

Bonjour à tous,

Tout d'abord, désolé si je ne suis pas dans le bon forum. J'ai cherché un forum conception mais je ne l'ai pas trouvé.

J'aurai souhaité avoir quelques conseils quant à la conception d'une DB devant gérer des infos en plusieurs langue (2 dans mon cas).

Je me rends bien compte que le système que j'ai mis en place actuellement n'est franchement pas top et qu'il faut que je décompose en plusieurs requête ce qui, je pense, aurait pu être fait en une seule si la DB avait été bien conceptualisée.

Pour le moment, j'ai quelque chose du genre (les clés primaires sont en gras souligné) :

tb_client :
- id : int
- nom : varchar(100)
- langage : smallint
- param1 : int
- param2 : int
...
- paramn : int


tb_langage :
- id : int
- description_fr : varchar(20)
- description_nl : varchar(20)

tb_param1 :
- id : int
- description_fr : varchar(100)
- description_nl : varchar(100)

Je ne vais pas plus loin, je pense que vous avez compris l'idée.

Du coup, si je veux imprimer un quelconque rapport (genre une commande par exemple) dans la langue du client, je dois d'abord faire une requête afin d'obtenir la langue du client pour que dans l'application je puisse "créer" la requête en prenant le champ de description correspondant à la langue.

En tant que programmeur, je me rend bien compte qu'il y a un problème car si un jour une 3e langue vient s'ajouter, mon application ne sera pas du tout fonctionnelle pour cette dernière. Je cherche donc à modifier la DB (tant pis si ça me prend pas mal de temps à tout refaire) de façon à ce que l'application n'ait pas besoin de traiter la langue.

J'ai songé à faire qqch du genre :

tb_paramx :
- id : int
- id_langue : int
- description : varchar(100)

Mais cela multiplierait le nombre de record de chaque table de paramètre par le nombre de langue utilisée. Et n'ayant aucune "vraie" formation en DB (j'ai lu des trucs par-ci par-là), je m'interroge sur les bienfaits de ce genre de pratique.

Je suis donc à la recherche d'avis de gens compétents en la matière pour me conseiller sur l'approche à adopter pour traiter ce genre de cas.

Merci d'avance.

Griftou.

[elsuket]

Bonjour,

En tant que programmeur, je me rend bien compte qu'il y a un problème car si un jour une 3e langue vient s'ajouter, mon application ne sera pas du tout fonctionnelle pour cette dernière. Je cherche donc à modifier la DB (tant pis si ça me prend pas mal de temps à tout refaire) de façon à ce que l'application n'ait pas besoin de traiter la langue.

Pourtant là vous avez l'air de bien vous être rendu compte que c'est un problème, et je ne peux que saluer votre démarche.

Je n'ai pas saisi le contexte complet de votre environnement.
L'idée c'est de créer une table de langues, et une table des traductions.

Supposons que le nom de vos clients peut être stocké en Thaï (exemple au hasard ... ou pas ), et dans une transcription du Thaï vers l'alphabet latin.

Vous aurez donc :

- une entité client
- une entité langue
- une entité client_nom_traduction

Les entités client et langue restent à peu près identiques à ce ce que vous avez pour le moment.
L'entité client_nom_traduction référence l'entité client et l'entité langue.
Pour tout tuple de cette entité, il existe une et une seule traduction.

Évidemment c'est un peu lourd si vous avez un nombre conséquent d'entités, mais cela a le mérite d'être flexible et robuste.

Pour exposer vos données, je ne sais pas si vous utilisez des procédures stockées, mais il vous suffit alors de passer un paramètre qui définit la langue dans laquelle l'interrogation ou la modification de données doit avoir lieu.
Mais visiblement, c'est déjà ce que vous faites.

Le forum que vous cherchiez est celui-ci.
Si vous réalisez votre implémentation sous SQL Server, nous serons néanmoins ravis de vous aider

@++

[Sergejack]

Je vous recommande de ne pas faire de table pour chaque champs à traduire mais plutôt pour l'ensemble des éléments sensibles à la langue pour chacune de vos table existante.

Vous devriez d'abord rajouter une table table_langue dans votre DB.
Et ensuite pour chaque table table_x une table table_trad_de_x lié à une ligne de table_x et une langue de la table table_langue.

Ensuite faite une vue pour chaque table originale.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
 
CREATE VIEW ....
SELECT
 T.id
 , T.c1
 , T.c2
, ISNULL(TRAD.c3, T.c3) AS c3 -- colonne sensible à la langue
, ISNULL(TRAD.c4, T.c4) AS c4 -- colonne sensible à la langue
FROM table_x AS T
CROSS JOIN table_langue AS L LEFT JOIN table_trad_de_x AS TRAD ON (
 TRAD.X_ID = T.id
 AND TRAD.LANG_ID = L.ID
)

Et ensuite pour être vraiment peinard, créer un trigger instead of pour l'insertion, la suppression et si besoin, l'update) de la vue pour pouvoir tout faire directement sur la vue depuis vos programmes.

[iberserk]

Et ensuite pour chaque table table_x une table table_trad_de_x lié à une ligne de table_x et une langue de la table table_langue.

Et ensuite pour être vraiment peinard, créer un trigger instead of pour l'insertion, la suppression et si besoin, l'update) de la vue pour pouvoir tout faire directement sur la vue depuis vos programmes.

Pensez aussi à un généreux TRIGGER DML sur vos table 'originales' pour appliquer les mêmes modifications sur la structure de vos tables 'tablelangue' :-)

[Kropernic]

Bonjour à tous,

Tout d'abord, merci pour vos réponses.

Par contre, peut-être que mon w-e prolongé y est pour quelque chose mais je ne suis pas sûr de bien comprendre tout ce que vous me proposez. D'autant plus que vous semblez vous contredire l'un l'autre ^^.

Je vais donc tenter de préciser le contexte de mon problème.

J'ai une table qui contient des informations sur des personnes dont voici une partie de la structure (la totalité serait trop longue ) (l'application est destinée à avoir une gestion du personnel interne à l'entreprise plutôt que de passer par un secrétariat social dès qu'on a besoin d'une info)

tb_personnel :
- registre_national : char(11) : primary key
- matricul : char(7)
- date_entree : datetime
- date_sortie : datetime
- nom : varchar(50)
- prenom : varchar(50)
- adresse : varchar(100)
- caractere_juridique_contrat : smallint
- categorie_salariale : smallint
- etat_civil : smallint
- langue : smallint
- fonction : smallint
- formation : smallint

Je pense que cela suffira pour mon problème.

J'ai donc chaque membre du personnel représenté dans cette table.
A côté de cela, j'ai une table langue qui se compose comme suit :

tb_langue :
- id : int : primary key (auto inc.)
- description_fr : varchar(100)
- description_nl : varchar(100)

Et en fait, j'ai utilisé la même structure que la table langue pour toutes les autres données qui varient suivant la langue (toutes les colonnes de types smallint dans la table personnel).

Exemple--> tb_caractere_juridique_contrat :
- id : int : primary key (auto inc.)
- description_fr : varchar(100)
- description_nl : varchar(100)

Déjà, si un jour on veut ajouter une langue, c'est la catastrophe (mais cela a très peu de chance d'arriver).

Maintenant, par rapport à vos réponses, ce que je n'ai pas compris c'est s'il me fallait des tables supplémentaires ou bien s'il "suffisait" que je modifie leur structure actuelle.

N'étant absolument pas formé en tant que DBA, j'aurai probablement beaucoup de mal à mettre en place la solution vraiment optimale que, j'imagine, vous ne manquerez pas de me proposer. Je recherche juste une solution conceptualisation de la DB qui soit plus flexible et qui ne demande pas de changer de requête dès qu'on change de langue.

Au risque de me répéter, j'ai songé à modifier la structure des tables de clés étrangères comme suit (exemple avec caractere_juridique_contrat) :

tb_caractere_juridique_contrat :
- id : smallint
- id_langue : smallint
- description : varchar(100)

Si je ne me trompe pas, cela résoudrait le problème de requête qu'il faut modifier pour chaque langue. Par contre cela va créer énormément plus de record que la version actuelle de la DB et j'ignore si cela peut poser des problèmes ou non (autres que des problèmes d'espace disque).

Concernant vos propositions de vues, de triggers et de procédures stockées, je crains fort de ne pas être compétent pour mettre cela en place à l'heure actuelle (mais des formations sont fort heureusement prévues). Histoire que vous vous rendiez compte de l'état de mes connaissances, mes programmes accèdent tous sur les DB avec le login "sa" et je gère les autorisations au sein de l'application en elle-même car il s'agit là de mon domaine d'expertise.

Voilà, vous pouvez jeter les pierres

Griftou.

[elsuket]

Maintenant, par rapport à vos réponses, ce que je n'ai pas compris c'est s'il me fallait des tables supplémentaires ou bien s'il "suffisait" que je modifie leur structure actuelle.

...

Au risque de me répéter, j'ai songé à modifier la structure des tables de clés étrangères comme suit (exemple avec caractere_juridique_contrat) :

tb_caractere_juridique_contrat :
- id : smallint
- id_langue : smallint
- description : varchar(100)

Si je ne me trompe pas, cela résoudrait le problème de requête qu'il faut modifier pour chaque langue. Par contre cela va créer énormément plus de record que la version actuelle de la DB et j'ignore si cela peut poser des problèmes ou non (autres que des problèmes d'espace disque).

La table tb_caractere_juridique_contrat telle que vous la proposez est correcte.

Il vous faudra, comme je vous l'ai décrit plus haut, ajouter une table pour chaque traduction à réaliser, et c'est ce que vous avez fait avec la table tb_caractere_juridique_contrat.

Les requêtes seront en conséquence écrites une seule fois, et vous pourrez ajouter autant de langues que vous voulez.

Il est vrai que cela va créer dans les tables de traduction beaucoup de lignes, mais comme votre table a peu de colonnes, les pages qui stockent les données seront très riches.
Sous réserve d'une indexation correcte et de requêtes propres, le nombre de lignes des tables de traduction ne devrait donc pas poser problème.

Concernant vos propositions de vues, de triggers et de procédures stockées, je crains fort de ne pas être compétent pour mettre cela en place à l'heure actuelle

- Une procédure stockée est un module T-SQL qui peut prendre en entrée des paramètres, et retourner des valeurs ou ensembles de valeurs (ou rien)
Elle est composée d'instruction T-SQL, paramétrées ou non.

- Une vue est, en SQL, une table particulière, qui est une représentation purement logique (sauf si elle est indexée, mais c'est un cas particulier d'optimisation) d'un ensemble
Elle est spécifiée par une requête SELECT et ne peut prendre aucun paramètre.
On la manipule comme une table (on l'interroge comme telle, on peut y attacher des triggers, ...)

- un trigger est un type particulier de module SQL qui est attaché à une table (ou à une base de données, ou à une instance SQL Server), qui ne peut prendre aucun paramètre.
Il exécute un traitement après (AFTER) ou au lieu (INSTEAD OF) qu'un certain type de transaction ait été effectué sur une table et c'est vous qui le choisissez (INSERT/UPDATE/DELETE).
Il permet (mais ce n'est pas obligatoire) d'effectuer des traitements à partir des données manipulées par la transaction qui a déclenché le trigger.

L'utilisation de triggers dans votre cas ne me semble pas nécessaire.
Les vues le seront peut-être, les procédures probablement, mais rien ne vous empêche de faire tout cela côté applicatif.
L'avantage des procédures stockées, c'est que côté applicatif, vous ne faites que l'appeler en lui passant des paramètres.

@++

[iberserk]

Mais je reste cependant toujours perplexe pour le cas de la table LANGUE_TRADUCTION(FK:LNG_ID1 et LNG_ID2, COLONNE TRADUCTION_VALUE) où LNG_ID1 est la valeur de la langue en elle-même et LNG_ID2 est la langue de la traduction.

Est-ce correct d'avoir 2 clefs étrangères qui référence la même clef primaire dans une table ?

Je ne comprends pas cette table,je pense que vous vous êtes mal compris...

[Kropernic]

Je ne comprends pas cette table,je pense que vous vous êtes mal compris...

Je vais essayer d'être plus clair.

Il y a donc une table personnel comme suit :
TABLE PERSONNEL(PK: PRS_REGISTRE_NATIONAL char(11),...,LANGUE smallint,...)
où la colonne langue est la langue maternelle de la personne.

Et donc, comme pour fonction, une table langue et une table langue_traduction.

Là où la table fonction_traduction référençait la table fonction et la table langue, la table langue_traduction référencera donc 2 fois la table langue.

N'étant pas rodé dans ce genre de pratique, cette situation me semble bizarre et je voulais savoir si cela vous paraissait normal.

Bien à vous,

Griftou.

[iberserk]

Compris... non je ne vois pas le problème...

[Kropernic]

Ok bien c'est cool alors ^^.

Je suis pas du tout DBA mais comme il n'y en a pas là où je bosse (je bosse pour une chaine de magasin qui a son propre p'tit service développement), et bien il faut bien que je m'y colle un peu.

Donc merci beaucoup !