Discussion :

[PIEPLU]

Bonjour,

Je viens vers vous pour connaitre les bonnes pratiques d'une base de données multilingues.

En gros, j'ai des produits à présenter, et cela, dans plusieurs langues. Mais pour ne pas faire n'importe quoi, j'aimerais bien comprendre comment on modélise ce genre de base.

Auriez-vous déjà fait ce genre de chose ?

Merci

[SQLpro]

Bonjour,

Je viens vers vous pour connaitre les bonnes pratiques d'une base de données multilingues.

En gros, j'ai des produits à présenter, et cela, dans plusieurs langues. Mais pour ne pas faire n'importe quoi, j'aimerais bien comprendre comment on modélise ce genre de base.

Auriez-vous déjà fait ce genre de chose ?

Merci

Compte tenu de la pauvreté des collations disponible dans MySQL, je vous souhaite bien du courage pour y parvenir... C'est presque infaisable avec MySQmerde !!!
A lire : http://blog.developpez.com/sqlpro/p1..._grand_folklor

A +

[al1_24]

Tu as deux choix : soit tu multiplies tes colonnes de libellé par le nombre de langues à gérer (pabô!), soit tu accoles une table de libellés à chaque table.

Prenons par exemple la table Produit qui possède la structure suivante, avec deux colonnes de libellés multilingues :

Code :

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

1
2
3
4
5
6
7
Table PRODUIT
(   ID_PRODUIT      AutoInc
,   REF_PRODUIT     Caractères
,   LIB_PRODUIT     Caractères
,   DESC_PRODUIT    Caractères
,   AUTRES          ...
)

Avec la première solution, si tu dois gérer le Français et l'Anglais, tu pourrais faire :

Code :

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

1
2
3
4
5
6
7
8
(   ID_PRODUIT      AutoInc
,   REF_PRODUIT     Caractères
,   LIB_PRODUIT_FR  Caractères
,   DESC_PRODUIT_FR Caractères
,   LIB_PRODUIT_EN  Caractères
,   DESC_PRODUIT_EN Caractères
,   AUTRES          ...
)

Pour accéder aux données, il faut une sélection du libellé

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
select  ID_PRODUIT
    ,   REF_PRODUIT
    ,   case :LANGUE 
            when    'FR'    then LIB_PRODUIT_FR
            when    'EN'    then LIB_PRODUIT_EN
        end as  LIB_PRODUIT
    ,   case :LANGUE 
            when    'FR'    then DESC_PRODUIT_FR
            when    'EN'    then DESC_PRODUIT_EN
        end as  DESC_PRODUIT
    ,   AUTRES
from    PRODUIT
;

Si dans quelques mois tu ajoutes l'Espagnol, il faut ajouter de nouvelles colonnes et modifier les requêtes.

Avec la seconde solution, tu auras deux tables :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
Table PRODUIT
(   ID_PRODUIT      AutoInc
,   REF_PRODUIT     Caractères
,   AUTRES          ...
)
Table PRODUIT_LIB
(   ID_PRODUIT      Numerique   references  PRODUIT(ID_PRODUIT)
,   LANGUE          Caractères
,   LIB_PRODUIT     Caractères
,   DESC_PRODUIT    Caractères
)

Pour accéder aux données, une requête qui ne change pas quel que soit le nombre de langues à gérer :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
select  prd.ID_PRODUIT
    ,   prd.REF_PRODUIT
    ,   lib.LIB_PRODUIT
    ,   lib.DESC_PRODUIT
    ,   prd.AUTRES
from    PRODUIT     prd
    inner join
        PRODUIT_LIB lib
        ON  lib.ID_PRODUIT  = prd.ID_PRODUIT
where   lib.LANGUE  = :LANGUE
;

Inutile de dire quelle solution a ma préférence

[escartefigue]

Le périmètre n'est pas très clair, pour moi
le cas le plus simple est celui où seuls les messages sont traduits dans plusieurs langues, auquel cas il suffit d'avoir un code langue (associé par exemple au client) et autant de tables de messages ou de partitions d'une table message que de code langue
le cas le plus riche est celui où les écrans de l'application, les états et autres documents doivent être traduits, en ce cas il existe des logiciels sur le marché adaptés aux différents types de plates formes

[Artemus24]

Salut à tous.

Je n'ai jamais géré des tables de langues, même quand je faisais du DB2. A vrai dire, le seul jeu de caractères admis sous IBM Z/Os est le EBCDIC.
Alors imagine un seul instant gérer de l'arabe ou du chinois. Je n'ai pas dit que cela était impossible, mais à moins de me tromper, on stocke cela dans le type BLOB.

Je reviens à MySql. Si je devais créer des tables pour gérer plusieurs langues, la première question que je me poserais, serait celle de sa gestion en Php (ou un autre langage) ?
L'idée qui me vient à l'esprit serait d'avoir les mêmes noms de colonnes mais pas les mêmes noms de tables.
Imaginons que le nom de la table soit le nom de la langue, il suffit alors de le mettre en paramètre dans une requête SQL.
La gestion devient facile car seul le nom de la table (cf. le libelle de la langue) suffit pour accéder à une langue.

En partant de cette idée, cela implique d'avoir autant de table qu'il existe de langues. Cela peut faire beaucoup de tables !
Et toutes les tables de langues ont la même structure.

La deuxième question concerne la façon de gérer une table de langue. Sous MySql cela se caractérise au niveau de la table par :

Code :

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

1
2
DEFAULT CHARSET=`latin1`
COLLATE=`latin1_general_ci`

Et comme le dit si bien SQLPRO, MySql n'est pas bien pourvu en jeu de caractères pour gérer les différentes langues.

Tu as deux choix : soit tu multiplies tes colonnes de libellé par le nombre de langues à gérer (pabô!), soit tu accoles une table de libellés à chaque table.

Ce n'est pabô comme tu dis, mais cela va vite devenir une usine à gaz si tu dois gérer chaque nom de colonnes langues.

Avec la première solution, si tu dois gérer le Français et l'Anglais,

Tu prends le cas le plus simple, deux langues pouvant être géré dans le même jeu de caractères 'latin1'.

Allez, soyons fou. Nous allons créer un dictionnaire dans toutes les langues du monde.

Notre planète est souvent comparée à une tour de Babel, avec ses 6800 langues réparties dans plus de 220 pays (ou États).

La première solution est impossible à gérer car il y a trop de langues.

Une solution basique est de créer une table par langue, ayant toujours les mêmes caractéristiques. C'est la seconde solution proposé par "al1_24".

On peut externaliser ce problème des langues en passant par un utilitaire qui va faire une traduction automatique. C'est la solution proposé par Escartefigue.

Je viens vers vous pour connaitre les bonnes pratiques d'une base de données multilingues.

Je rejoins Escartefigue sur le fait que le périmètre indiqué par Pieplu est flou.

Combien de langues allez-vous utiliser dans votre base de données ?

Quel est la fréquence des changements de ces libellés ?
Est-ce une personne qui va faire la saisie ou est-ce un fichier langue que vous allez charger dans votre base de données ?
Si c'est une personne, il vous faut un clavier spéciale pour chaque langue.
En chinois, pour créer un seul idéogramme, cela correspond à la frappe de plusieurs touches. Idem pour l'arabe.

Est-ce que ce sont juste des libellés de produits ou est-ce la totalité de votre site (texte, voir image avec texte, logo ...) ?
En général, on utilise de l'UTF-8, mais celui-ci occupe trois octets au maximum pour représenter un seul caractère en mémoire et il n'est pas complet.
Il existe une nouvelle norme le 'UTFMB4' qui utilise jusqu'à quatre octets.
Est-ce que ce jeu de caractères est disponible dans votre SGBDR ? Et en admettant qu'il le soit, est-il complet ?

Et surtout comment allez-vous gérer le sens de la lecture ? En arabe, c'est de droite à gauche.
En chinois traditionnel, je crois que c'est de haut en bas, et de droite vers la gauche, sans ponctuation. Bon maintenant, le chinois se lit comme chez nous.

Il faut savoir qu'un jeu de caractères comme le 'latin1' représente la codification de vos caractères en mémoire.
Le 'latin1' est ce que l'on appelle un jeu de caractères régional, c'est-à-dire propre à un pays. Il est simple car un caractère occupe un seul octet.
Le UTF-8 (jeu de caractères) basé sur l'unicode à pour vocation de regrouper tous les jeux de caractères les plus usités dans le monde.

Ne confondez pas le jeu de caractères avec la police de caractères, qui sert à l'affichage des caractères à l'écran.
Pratiquement, il faut une police de caractères par alphabet utilisé pour vos langues.
Et l'on n'écrit pas de la même façon (je parle du dessin des caractères) du latin et du chinois, par exemple.
Le chinois à l'affichage utilise beaucoup plus de place que le latin. Donc il va falloir aussi gérer l'espacement et l'occupation des caractères à l'écran.

Je m'arrête là. Tout ce que je peux dire, c'est bon courage ! Car vous allez entrer dans une usine à gaz juste pour gérer plusieurs langues.

@+

[SQLpro]

e n'ai pas dit que cela était impossible, mais à moins de me tromper, on stocke cela dans le type BLOB.

Oui tu te trompes. C'est parfaitement possible. Il faut utiliser un type de données de chaines de caractères supportant l'UNICODE (NCHAR/NVARCHAR dans la norme SQL), mais il faut surtout que le SGBDR puisse supporter les collations des différentes langues dont certaines se lisent de droite à gauche et avec les conséquences que cela a dans les fonctions (par exemple SUBSTRING, sui doit donc marcher "à l'envers" !)... Ce que fait SQL Server sans problème !

Comme montré dans l'image, la fonction SUBSTRING parcours à l'envers les caractères arabes...

Je reviens à MySql. Si je devais créer des tables pour gérer plusieurs langues, la première question que je me poserais, serait celle de sa gestion en Php (ou un autre langage) ?
L'idée qui me vient à l'esprit serait d'avoir les mêmes noms de colonnes mais pas les mêmes noms de tables.
Imaginons que le nom de la table soit le nom de la langue, il suffit alors de le mettre en paramètre dans une requête SQL.
La gestion devient facile car seul le nom de la table (cf. le libelle de la langue) suffit pour accéder à une langue.

c'est du grand n'importe quoi...
Un SGBDR est fait pour traiter des données. Un langage de programmation pour faire des traitements. La collecte et la manipulation des données relève du SGBDR pas du PHP ou autre langage sinon vous allez fabriquer un veau !
Et multiplier le nombre de table n'est pas la bonne solution.

En partant de cette idée, cela implique d'avoir autant de table qu'il existe de langues. Cela peut faire beaucoup de tables !
Et toutes les tables de langues ont la même structure.

La deuxième question concerne la façon de gérer une table de langue. Sous MySql cela se caractérise au niveau de la table par :

Code :

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

1
2
DEFAULT CHARSET=`latin1`
COLLATE=`latin1_general_ci`

Et comme le dit si bien SQLPRO, MySql n'est pas bien pourvu en jeu de caractères pour gérer les différentes langues.

Ben gratuite, ça veut souvent dire, camelote !

Ce n'est pabô comme tu dis, mais cela va vite devenir une usine à gaz si tu dois gérer chaque nom de colonnes langues.


Tu prends le cas le plus simple, deux langues pouvant être géré dans le même jeu de caractères 'latin1'.

Allez, soyons fou. Nous allons créer un dictionnaire dans toutes les langues du monde.

La première solution est impossible à gérer car il y a trop de langues.

Une solution basique est de créer une table par langue, ayant toujours les mêmes caractéristiques. C'est la seconde solution proposé par "al1_24".

On peut externaliser ce problème des langues en passant par un utilitaire qui va faire une traduction automatique. C'est la solution proposé par Escartefigue.

Là viennent les bonnes questions... Sans une étude sérieuse, c'est perdu d'avance !

Je rejoins Escartefigue sur le fait que le périmètre indiqué par Pieplu est flou.

Combien de langues allez-vous utiliser dans votre base de données ?

Quel est la fréquence des changements de ces libellés ?
Est-ce une personne qui va faire la saisie ou est-ce un fichier langue que vous allez charger dans votre base de données ?
Si c'est une personne, il vous faut un clavier spéciale pour chaque langue.
En chinois, pour créer un seul idéogramme, cela correspond à la frappe de plusieurs touches. Idem pour l'arabe.

Est-ce que ce sont juste des libellés de produits ou est-ce la totalité de votre site (texte, voir image avec texte, logo ...) ?
En général, on utilise de l'UTF-8, mais celui-ci occupe trois octets au maximum pour représenter un seul caractère en mémoire et il n'est pas complet.
Il existe une nouvelle norme le 'UTFMB4' qui utilise jusqu'à quatre octets.
Est-ce que ce jeu de caractères est disponible dans votre SGBDR ? Et en admettant qu'il le soit, est-il complet ?

Et surtout comment allez-vous gérer le sens de la lecture ? En arabe, c'est de droite à gauche.
En chinois traditionnel, je crois que c'est de haut en bas, et de droite vers la gauche, sans ponctuation. Bon maintenant, le chinois se lit comme chez nous.

Il faut savoir qu'un jeu de caractères comme le 'latin1' représente la codification de vos caractères en mémoire.
Le 'latin1' est ce que l'on appelle un jeu de caractères régional, c'est-à-dire propre à un pays. Il est simple car un caractère occupe un seul octet.
Le UTF-8 (jeu de caractères) basé sur l'unicode à pour vocation de regrouper tous les jeux de caractères les plus usités dans le monde.

Ne confondez pas le jeu de caractères avec la police de caractères, qui sert à l'affichage des caractères à l'écran.
Pratiquement, il faut une police de caractères par alphabet utilisé pour vos langues.
Et l'on n'écrit pas de la même façon (je parle du dessin des caractères) du latin et du chinois, par exemple.
Le chinois à l'affichage utilise beaucoup plus de place que le latin. Donc il va falloir aussi gérer l'espacement et l'occupation des caractères à l'écran.

Je m'arrête là. Tout ce que je peux dire, c'est bon courage ! Car vous allez entrer dans une usine à gaz juste pour gérer plusieurs langues.

@+

Pour info, il y a 17 ans, nous avons récupéré un site de Sodexho qui avait été commencé avec Oracle qui gère pas du tout les collations (il y a cependant un truc imbitable appelé NLS...) et nous l'avons refait avec SQL Server 7 et il est totalement multilingue (30 langues exigées au départ dont le mandarin, le japonais et l'arabe...)

A +

[escartefigue]

J'ai eu une expérience similaire dans un contexte différent, il s'agissait d'une entreprise qui partageait des données référentielles dans une base unique, mais qui avait n itérations de database métier distinctes (issues de fusion de filiales dont les S.I. n'avaient jamais convergé)

L'astuce choisie par cette entreprise était de créer des objets de type ALIAS (objet DB2 équivalent du SYNOMYM de SQL Server) pointant sur des tables différentes mais de même structure (DDL identique table et index)
Plusieurs ALIAS portant le même nom étaient créés sur des shémas différents, le traitement, en fonction de la filiale, se connectait sur le bon schema
Les requetes étaient donc identiques quelques soit l'alias choisi et sans besoin de faire du SQL dynamique.

Par contre, à ma connaissance, MySQL ne connait pas les objets de type SYNONYM ou ALIAS

[Artemus24]

Salut SQLPRO.

Oui tu te trompes

Je parlais du type BLOB ! Je crois en fait que c'était un CLOB.

Et pour venir me contredire, vous me parlez d'UNICODE, de COLLATION, sur SQL Server, la dernière version professionnelle qui vous possédez.

Or ce dont je parlais, c'est la version DB2 Z/OS (donc sous IBM) que j'ai utilisé --> version 7, la dernière version que j'ai utilisé.
Je prends le "Reference Guide Version 7, DB2 for z/os and os/390" que j'ai en ma possession, et qui date de 2002.
Je suis désolé pour vous, mais le seul jeu de caractères reconnu sous IBM est l'EBCDIC.
Et il n'est fait aucune référence ni à l'unicode ni à collation qui sont des concepts propre à la micro-informatique.

Et même si c'était le cas, comment voulez-vous gérer cela sur des machines qui ne connaissent que l'EBCDIC ?
L'émulateur dont on se servait pour se connecter à IBM se nomme "EXTRA!". Sa fonction est d'emuler le comportement des terminaux 3279 d'IBM.

On se servait des tables DB2, juste pour le stockage des données (serveur).
Le traitement se faisait sur des PC (micro-informatique) dans un autre environnement (client) qui pouvait interpréter correctement le jeu de caractères utilisés.
Comment cela était géré sur le PC ? je l'ignorais car je ne faisais que du gros système.

c'est du grand n'importe quoi...

Or mes propos sont ceux aussi de al1_24. Pourquoi ne lui dites-vous pas que c'est du grand n'importe quoi ? A oui, c'est un modérateur.

Un SGBDR est fait pour traiter des données.

Ca par contre, c'est du grand n'importe quoi. Un SGBD ne traite pas les données.

La collecte et la manipulation des données relève du SGBDR

Manipuler des données et les traiter n'ont pas le même sens sémantique.
DML Signifie "Langage de manipulation de données". Ou voyez vous le mot traiter ?
Si vous en êtes encore à confondre ses deux mots, manipuler et traiter, je comprends que mes propos vous semble obscure.

Et multiplier le nombre de table n'est pas la bonne solution.

quel est la solution selon vous ? C'est pourtant ce qui se fait et c'est même ce qui est recommandé de faire. Cf. les explications données par al1_24.

A oui, vous ne faites pas de programmations et donc vous ne savez pas de quoi vous parler !

Là viennent les bonnes questions...

Comme vous soulevez le problème, j'aimerai connaitre, selon vous, les bonnes questions à se poser ?

L'astuce choisie par cette entreprise était de créer des objets de type ALIAS (objet DB2 équivalent du SYNOMYM de SQL Server) pointant sur des tables différentes mais de même structure (DDL identique table et index)

Mefie toi, il va dire que c'est du grand n'importe quoi. Selon SQLPRO, tout ce qui se fait en dehors de SQL Server, c'est de la merde !

Plusieurs ALIAS portant le même nom étaient créés sur des shémas différents, le traitement, en fonction de la filiale, se connectait sur le bon schema
Les requetes étaient donc identiques quelques soit l'alias choisi et sans besoin de faire du SQL dynamique.

Tu vas dans le même sens que j'ai indiqué. Sauf que tu as à ta disposition une solution plus souple que ce dont je disposais à mon époque.
Je ne connais pas le type ALIAS. Il n'est pas référencé dans mon "reference guide".

Par contre, à ma connaissance, MySQL ne connait pas les objets de type SYNONYM ou ALIAS

Il ne faut pas se focaliser sur la solution que tu connais. En php, la requête se construit à partir d'une chaîne de caractères.
Il suffit de substituer le nom de la table langue par une autre, en gardant le même squelette de ta requête.
Ce n'est donc pas un problème incontournable mais juste applicatif. Autrement dit, de la mise en forme. Et ce n'est pas non plus du SQL Dynamique.

@+

[escartefigue]

L'astuce choisie par cette entreprise était de créer des objets de type ALIAS (objet DB2 équivalent du SYNOMYM de SQL Server) pointant sur des tables différentes mais de même structure (DDL identique table et index)
Plusieurs ALIAS portant le même nom étaient créés sur des shémas différents, le traitement, en fonction de la filiale, se connectait sur le bon schema
Les requetes étaient donc identiques quelques soit l'alias choisi et sans besoin de faire du SQL dynamique.
Par contre, à ma connaissance, MySQL ne connait pas les objets de type SYNONYM ou ALIAS

Tu vas dans le même sens que j'ai indiqué. Sauf que tu as à ta disposition une solution plus souple que ce dont je disposais à mon époque.

Tout à fait

Je ne connais pas le type ALIAS. Il n'est pas référencé dans mon "reference guide".

A ma connaissance, les alias DB2 existaient déjà en DB2V5 il y a 20 ans

Il ne faut pas se focaliser sur la solution que tu connais. En php, la requête se construit à partir d'une chaîne de caractères.
Il suffit de substituer le nom de la table langue par une autre, en gardant le même squelette de ta requête.
Ce n'est donc pas un problème incontournable mais juste applicatif. Autrement dit, de la mise en forme. Et ce n'est pas non plus du SQL Dynamique.

La différence n'est pas mince, je préfère une solution qui s'appuie sur une fonction standard du SGBD (alias ou synonym selon)

[Artemus24]

Salut Escartefigue.

Tout à fait

SQLPRO est certainement un excellent professeur, et je sais qu'il est passionné par ce qu'il fait. Cf. les livres qu'il écrit, les didacticiels sur les bases de données ...
Mais il a un manque d'expérience professionnel. Cela se fait ressentir dans les remarques qu'il fait.
Ce qui m'énerve cher lui, c'est qu'en dehors de SQL Server, il n'a aucun respect pour les autres SGBD. A part cela, je l'aime bien !

A ma connaissance, les alias DB2 existaient déjà en DB2V5 il y a 20 ans

Je n'ai aucun souvenir de cela. J'ai pourtant regardé le dernier "reference guide" que je possède, et je n'ai rien trouvé à ce sujet.
Comme je n'ai plus la possibilité de travailler avec DB2 gros système, tout ce que je te dis sont des vieux souvenirs.

La différence n'est pas mince, je préfère une solution qui s'appuie sur une fonction standard du SGBD (alias ou synonym selon)

Bien sûr ! Je préfère comme toi, utiliser une fonction standard que de faire du bricolage.
Mais quand tu n'as pas le choix, il faut faire avec ce que tu as à ta disposition.

@+

[SQLpro]

Salut SQLPRO.

Et pour venir me contredire, vous me parlez d'UNICODE, de COLLATION, sur SQL Server, la dernière version professionnelle qui vous possédez.

Non, je vous parle de la norme SQL et je l'illustre avec SQL Server qui est l'un des SGBDR les plus normatif...

Or ce dont je parlais, c'est la version DB2 Z/OS (donc sous IBM) que j'ai utilisé --> version 7, la dernière version que j'ai utilisé.
Je prends le "Reference Guide Version 7, DB2 for z/os and os/390" que j'ai en ma possession, et qui date de 2002.
Je suis désolé pour vous, mais le seul jeu de caractères reconnu sous IBM est l'EBCDIC.

L'EBCDIC est un encodage propriétaire breveté par IBM avec 8 déclinaisons différentes et a été fait dans le but de rendre incompatible les échanges informatiques avec d'autres machine en dehors de l'hégémonie IBM de l'époque... Donc rien à voir avec SQL,et les collations :::

Et il n'est fait aucune référence ni à l'unicode ni à collation qui sont des concepts propre à la micro-informatique.

Désolé de vous le dire, mais la vous déraillez complément. Il est temps de vous recycler !
Pour cela lisez les articles de Wikipedia suivant :
UNICODE
COLLATION

Voici maintenant un extrait de la norme SQL qui fait mention de la notion de collation :

Et même si c'était le cas, comment voulez-vous gérer cela sur des machines qui ne connaissent que l'EBCDIC ?

C'est vous qui prenez comme exemple EBCDIC qui n'existe que dans l'univers IBM (qui d’ailleurs l'a relativement abandonné depuis quelques temps) encodage qui n'existe pas dans MySQL !

L'émulateur dont on se servait pour se connecter à IBM se nomme "EXTRA!". Sa fonction est d'emuler le comportement des terminaux 3279 d'IBM.

[...]

Ca par contre, c'est du grand n'importe quoi. Un SGBD ne traite pas les données.

Et à votre avis à quoi servent les procédures stockées ? A faire des IHM ??????? Atterrissez ! revenez sur terre !!! les procédures stockées ont été inventé pas l'ancêtre de SQL Server qui s’appelait Sybase SQL Server en 1986...

Manipuler des données et les traiter n'ont pas le même sens sémantique.
DML Signifie "Langage de manipulation de données". Ou voyez vous le mot traiter ?

la norme SQL est composées de nombreuses parties don le DML n'en est qu'une. A la page 9 de mon livre sur SQL (que je vous ais d'ailleurs offert) vous verrez le tableau synoptique des composantes du SQL et ou le DDl, DML, DCL et TCL, il y a aussi le SQL procédural dont les sous parties sont :

• SQL embedded
• Call Level Interface
• Persistent Stored Module

Sans doute êtes vous trop âgé pour avoir connu la programmation de procédures stockées (appelés autrefois procédures cataloguées) et autres déclencheurs et UDF... Qui font parties intégrantes de PSM et cela dans presque la plupart des bons SGBDR, y compris le désastreux MySQL !

[...]

A oui, vous ne faites pas de programmations et donc vous ne savez pas de quoi vous parler !

Il est vrai que depuis quelques années je n'en fait pratiquement plus. mais j'ai été développeur et chef de projet pendant 15 ans avant de me spécialiser depuis 1999 dans l'univers des SGBDR de la modélisation et de SQL Server en particulier... Et je continue de développer encore aujourd'hui de nombreuses procédures stockées pour mes clients dont certaines sont mise à disposition sur ce site dans sqlpro...

A +

[SQLpro]

Une solution beaucoup plus pragmatique est de créer une table des littéraux multilingues (toutes les colonnes littérales n'ayant pas besoin de traduction)
De faire référence dans votre table à un id de libellé et :

• soit dans le contexte de l'utilisateur SQL appelant, livrer le bon littéral dans la bonne langue
• soit dans la saisie de taguer la langue dans une colonne de la table

Exemple :

Code :

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

1
2
3
4
5
6
7
8
9
10
CREATE TABLE T_LANGUE_LNG
(LNG_ID          SMALLINT PRIMARY KEY,
 LNG_LANGUE      VARCHAR(60) NOT NULL UNIQUE);
 
CREATE TABLE T_LIBELLE_LBL
(LBL_ID          BIGINT NOT NULL PRIMARY KEY,
 LBL_REF         INT NOT NULL, 
 LNG_ID          SMALLINT FOREIGN KEY REFERENCES T_LANGUE_LNG (LNG_ID),
 LBL_LIBELLE     NVARCHAR(1000) COLLATE UNICODE,
 CONSTRAINT UK_LBL_REF_LNG UNIQUE (LBL_REF, LNG_ID));

Dans vos table de production, vous aurez par exemple...
1) Une table des produits multilingue :

Code :

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

1
2
3
4
5
6
CREATE TABLE T_PRODUIT_PRD
(PRD_ID          INT PRIMARY KEY,
 LBL_REF         INT NOT NULL,
 LNG_ID          SMALLINT,
 CONSTRAINT FK_PRD_LBL FOREIGN KEY (LBL_REF, LNG_ID) 
                       REFERENCES T_LIBELLE_LBL (LBL_REF, LNG_ID));

La colonne LNG_ID sera toujours NULLe et il faudra aller recherche le libelle en fonction de la langue de l'utilisateur

2) une table de réclamation :

Code :

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

1
2
3
4
5
6
7
CREATE TABLE T_RECLAMATION_RCM
(RCM_ID          INT PRIMARY KEY,
 RCM_DATEHEURE   TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP,
 LBL_REF         INT NOT NULL,
 LNG_ID          SMALLINT NOT NULL,
 CONSTRAINT FK_PRD_LBL FOREIGN KEY (LBL_REF, LNG_ID) 
                       REFERENCES T_LIBELLE_LBL (LBL_REF, LNG_ID));

Dans ce dernier cas il n'y aura qu'une seule langue et LNG_ID doit être renseigné !

Après, en fonction de la charge de la table, vous pourrez partitionner la table des langues en fonction de l'utilisation de chacune des langues....
Cette table facilite aussi grandement les traductions en concentrant toute la mécanique dans une seule table !

A +

[Artemus24]

Salut SQLPRO.

L'EBCDIC est un encodage propriétaire breveté par IBM avec 8 déclinaisons différentes et a été fait dans le but de rendre incompatible les échanges informatiques avec d'autres machine en dehors de l'hégémonie IBM de l'époque... Donc rien à voir avec SQL,et les collations :::

Quand vous faites un accès à Wikipedia, essayez de recopier correctement le texte. C'est un encodage sur huit bits et il n'existe pas 8 déclinaisons mais 6 : https://fr.wikipedia.org/wiki/Extend...terchange_Code
Je n'ai connu qu'une seule déclinaison de l'EBCDIC sous IBM MVS TSO/ISPF et cela est déjà bien suffisant !
De plus, l'EBCDIC est apparu à un moment ou le concept de SQL et des collations n'existaient même pas (origine vers 1890 à partir du code Hollerith, mais a subit quelques changements depuis). L'ascii a été inventé en 1961.

Désolé de vous le dire, mais la vous déraillez complément.

Je me demande si vous avez bien compris ce dont je parle.
1) les mainframes ne sont pas connectés à internet. Donc pas d'accès au WEB. Les collations ont été inventés pour gérer les différents jeu de caractères en html, c'est-à-dire sous le WEB.

2) Sous IBM, l'architecture est le SNA et non le TCP-IP. Les émulateurs de terminaux 3270 utilisent le SNA mais encapsulé sous TCP-IP.

3) l'accès à un mainframe IBM se fait par un émulateur de terminaux 3270.

4) Il n'y a aucun raison de traiter différents jeu de caractères avec collation car nous sommes dans un environnement propriétaire. Seul l'EBCDIC est la codification utilisée sous IBM.

5) IBM n'est pas obligé de suivre les normes ! Pourquoi ? Parce que c'est un environnement propriétaire et surtout parce qu'ils ont le monopole des Mainframes dans le monde.

Pour cela lisez les articles de Wikipedia suivant :

Ce sont des normes pour le monde du web, et plus particulièrement pour la micro-informatique. Quand allez-vous comprendre que cela ne s'applique pas au mainframe ?
Mais ça, vous ne pouvez pas le savoir, vu que vous n'avez jamais travailler dans ce genre d'environnement.

Et à votre avis à quoi servent les procédures stockées ?

A manipuler les données ! Entre autre, à faire des extraction en appliquant les opérateurs de la théorie des ensembles.
Tant qu'il s'agit de se simplifier les extractions, la procédure stockée est bien adaptée pour cela.

Si vous détourner votre SGBD pour faire de la présentation, des calculs, des contrôles ou je ne sais quoi d'autre, vous le monopolisez avec des tâches qui ne lui incombe pas.
D'autant qu'en procédant ainsi, vous pénalisez les accès concurrents des autres utilisateurs en diminuant les performances de leurs accès.
Il faudrait ne pas oublier que vous n'êtes pas seul à travailler sur une machine et vous ne pouvez pas faire n'importe sous prétexte qu'on peut le faire.
Les traitements sont réservés au langage de programmation car ils sont adaptés à cela.

Imaginez un seul instant qu'un traitement peut se décomposer en plusieurs tâches indépendantes que vous pouvez traiter en parallèle afin de gagner du temps sur votre ordinateurs multicœurs.
Croyez-vous qu'il soit opportun d'utiliser des procédures stockées qui sont de toutes évidences mono-tâches ? Tout ce que vous faites, c'est perdre du temps, alors que vous pourriez en gagner en rendant ces tâches parallèles.
Il vaut mieux gérer les accès concurrents dans un langage de programmation adapté à cela

Une solution beaucoup plus pragmatique est de créer une table des littéraux multilingues

Vous nous dites que SQL Server est très riche en collation et dans l'exemple que vous nous donnez, vous mettez tout en unicode.
N'est-ce pas réducteur que d'utiliser une seule collation ? Je m'attendais à trouver un libelle avec la collation adaptée, et ce par type de langue.
Vos tables restent valables pour des langues basées sur l'alphabet latin. Mais quand est-il si vous ajoutez le chinois ou l'arabe ?

Tant que ce sont juste des libelles (du texte court), je pense que c'est largement suffisant comme approche.
Je ne voie que deux contraintes à cela :
--> une petite volumétrie (quelques milliers de libellés).
--> une grande stabilité (pas ou peu de changement dans les libellés).

Cela doit répondre à l'attente de PIEPLU.

@+

[SQLpro]

Vous dites beaucoup de choses fausses... Je n'ai pas le temps de vous répondre sur tout, car je ne suis pas retraité et je travaille en ce moment en presta chez un de mes clients... mais je compléterais.
En plus vous avez pas de pot car je suis en train de commencer à centraliser toute la documention pour l'écriture d'un livre sur l'histoire du logiciel.... Donc, toutes ces choses me sont facile à vous renvoyer !

Salut SQLPRO.

Quand vous faites un accès à Wikipedia, essayez de recopier correctement le texte. C'est un encodage sur huit bits et il n'existe pas 8 déclinaisons mais 6 : https://fr.wikipedia.org/wiki/Extend...terchange_Code
Je n'ai connu qu'une seule déclinaison de l'EBCDIC sous IBM MVS TSO/ISPF et cela est déjà bien suffisant !
De plus, l'EBCDIC est apparu à un moment ou le concept de SQL et des collations n'existaient même pas (origine vers 1890 à partir du code Hollerith, mais a subit quelques changements depuis). L'ascii a été inventé en 1961.

Non, en 1963 et en reprenant pour l'essentiel le code des Telex...
A lire :
http://ascii-world.wikidot.com/history
https://www.smashingmagazine.com/201...haracter-sets/

Je me demande si vous avez bien compris ce dont je parle.
1) les mainframes ne sont pas connectés à internet. Donc pas d'accès au WEB. Les collations ont été inventés pour gérer les différents jeu de caractères en html, c'est-à-dire sous le WEB.

Pas du tout.... les collations sont apparues dès qu'il y a eu des problèmes de comparaisons de chaines....
Les premières études remonte en 1930... (Greg, W. W. 1934. "A Formulary of Collation." Library. 14, no. 4: 365-382)
Les premières applications informatiques datent des années 70 (Oakman, Robert L. The Present State of Computerized Collation: A Review Article. Columbia, S.C.: University of South Carolina Press, 1972)

2) Sous IBM, l'architecture est le SNA et non le TCP-IP. Les émulateurs de terminaux 3270 utilisent le SNA mais encapsulé sous TCP-IP.

3) l'accès à un mainframe IBM se fait par un émulateur de terminaux 3270.

4) Il n'y a aucun raison de traiter différents jeu de caractères avec collation car nous sommes dans un environnement propriétaire. Seul l'EBCDIC est la codification utilisée sous IBM.

5) IBM n'est pas obligé de suivre les normes ! Pourquoi ? Parce que c'est un environnement propriétaire et surtout parce qu'ils ont le monopole des Mainframes dans le monde.

Vous ne trouvez pas qu'on est un peu loin des problématiques de MySQL ?

Ce sont des normes pour le monde du web, et plus particulièrement pour la micro-informatique. Quand allez-vous comprendre que cela ne s'applique pas au mainframe ?
Mais ça, vous ne pouvez pas le savoir, vu que vous n'avez jamais travailler dans ce genre d'environnement.

Non, pas du tout spécifique au web.... En 1970 les collations commencent d'être utilisées et le web n'existera qu'en 1990... 20 ans de différence. Le problème c'est que comme vous n'avez visiblement rien fait d'autre dans votre vie que de l'IBM, vous jugez toute l'informatique à l'aune d'IBM et de ses mainframes..... Recyclez vous !
Pour info, j'ai commencé l'informatique en 1979 sous IBM 360 en assembleur et en CoBOL, puis sur 370 puis sous 9370 (VM/CMS) !

A manipuler les données ! Entre autre, à faire des extraction en appliquant les opérateurs de la théorie des ensembles.
Tant qu'il s'agit de se simplifier les extractions, la procédure stockée est bien adaptée pour cela.

Si vous détourner votre SGBD pour faire de la présentation, des calculs, des contrôles ou je ne sais quoi d'autre, vous le monopolisez avec des tâches qui ne lui incombe pas.
D'autant qu'en procédant ainsi, vous pénalisez les accès concurrents des autres utilisateurs en diminuant les performances de leurs accès.
Il faudrait ne pas oublier que vous n'êtes pas seul à travailler sur une machine et vous ne pouvez pas faire n'importe sous prétexte qu'on peut le faire.
Les traitements sont réservés au langage de programmation car ils sont adaptés à cela.

Imaginez un seul instant qu'un traitement peut se décomposer en plusieurs tâches indépendantes que vous pouvez traiter en parallèle afin de gagner du temps sur votre ordinateurs multicœurs.
Croyez-vous qu'il soit opportun d'utiliser des procédures stockées qui sont de toutes évidences mono-tâches ? Tout ce que vous faites, c'est perdre du temps, alors que vous pourriez en gagner en rendant ces tâches parallèles.
Il vaut mieux gérer les accès concurrents dans un langage de programmation adapté à cela


Vous nous dites que SQL Server est très riche en collation et dans l'exemple que vous nous donnez, vous mettez tout en unicode.
N'est-ce pas réducteur que d'utiliser une seule collation ? Je m'attendais à trouver un libelle avec la collation adaptée, et ce par type de langue.
Vos tables restent valables pour des langues basées sur l'alphabet latin. Mais quand est-il si vous ajoutez le chinois ou l'arabe ?

Vous confondez toujours jeu de caractères et collation (erreur hélas commune). Certes il existe toujours une collation par défaut associé à un jeu de caractères. Mais le but d'une collation est d'être indépendante du jeu de caractères. C'est fondamental pour rester indépendant de la couche physique et traiter non des chaines, mais de la sémantique....

Tant que ce sont juste des libelles (du texte court), je pense que c'est largement suffisant comme approche.
Je ne voie que deux contraintes à cela :
--> une petite volumétrie (quelques milliers de libellés).
--> une grande stabilité (pas ou peu de changement dans les libellés).

Cela doit répondre à l'attente de PIEPLU.

@+

A +

[escartefigue]

Il est temps de recentrer le débat sur :

Bonjour,
Je viens vers vous pour connaitre les bonnes pratiques d'une base de données multilingues.
En gros, j'ai des produits à présenter, et cela, dans plusieurs langues. Mais pour ne pas faire n'importe quoi, j'aimerais bien comprendre comment on modélise ce genre de base.
Auriez-vous déjà fait ce genre de chose ?
Merci

[Artemus24]

Salut SQLPRO.

Vous dites beaucoup de choses fausses...

Vous avez une culture micro alors que j'ai une culture mainframe. Toute la divergence de notre vision de l'informatique vient de là.

De plus, je ne me suis jamais intéressé à la norme car dans un environnement propriétaire (IBM, voire aussi BULL), cela ne nous sert à rien.

Non, en 1963 et en reprenant pour l'essentiel le code des Telex...

Encore une contradiction. vous me dites non pour l'année 1961, mais le premier lien que vous me donné, je lis : "1961 The Work Begins".

les collations sont apparues dès qu'il y a eu des problèmes de comparaisons de chaines....

C'est à croire que l'on a pas travaillé sur les mêmes ordinateurs.
Maintenant si vous me parlez encore des normes, je n'en ai rien à faire.
Ce n'est pas parce que quelqu'un a imaginé quelque chose que cela existe obligatoirement sur un ordinateur.

Sous mainframe, le concept de collation n'existe pas. Il n'y a qu'un seul jeu de caractères et c'est tout.
Les comparaisons se font dans l'ordre de rangement des caractères de la table utilisé (ASCII ou EBCDIC).
D'où le fait qu'en ASCII les chiffres sont classés avant les lettres, à l'inverse de l'EBCDIC.

En 1970 les collations commencent d'être utilisées et le web n'existera qu'en 1990...

Les prémisses ont commencé dans le monde de la micro, puis ensuite au monde WEB. Donc aucun rapport avec les mainframe.
En fait, et je ne sais pas si c'est volontaire de votre part, mais vous occultez complètement le monde du gros système.

Le problème c'est que comme vous n'avez visiblement rien fait d'autre dans votre vie que de l'IBM, vous jugez toute l'informatique à l'aune d'IBM et de ses mainframes...

Erreur de votre part !
J'ai commencé par travail sur un MITRA 125, un PDP11 et un IRIS 80.
Ensuite, j'ai travaillé sur IBM VM/CMS, avant de faire du MVE TSO/ISPF, puis du BULL gcos 7 et gcos 8, et j'ai aussi fait de l'UNIX (HP, Devon, ...).
Je n'ai jamais travaillé sur de la micro. Je m'y suis mis depuis que je suis à la retraite.
J'ai bien plus d'expérience en informatique que vous ! Vous voulez que j'énumère toutes les bases de données sur lesquelles j'ai travaillé ?
Tout ce que l'on m'a demandé, c'est d'être opérationnel sur le travail demandé.
Le pourquoi du comment qui vous intéresse le plus, n'est pas ce qui intéresse le monde du travail.
Surtout dans le monde du service où le temps est primordial.
Si on vous demande de faire de la merde et c'est le choix du client, et bien vous vous pliez à ses exigences.

Et comme j'ai du temps à perdre, je me consacre à étudier ce que je ne connais pas.

Recyclez vous !

Et vous, soyez un plus tolérant ! Tout ne tourne pas autour de votre expérience.

Pour info, j'ai commencé l'informatique en 1979 sous IBM 360 en assembleur et en CoBOL, puis sur 370 puis sous 9370 (VM/CMS) !

Je ne vous demande pas votre C.V. mais juste de comprendre qu'il existe autre chose que la micro-informatique.
Avant de faire du cobol, j'ai fait du basic, du fortran, du pl1, du palmes, du gap (rpg) ... et je ne parle même pas des assembleurs.

Vous confondez toujours jeu de caractères et collation (erreur hélas commune).

Non, je ne confonds rien du tout. Je constate surtout que vous avez des difficultés à me comprendre.

C'est fondamental pour rester indépendant de la couche physique et traiter non des chaines, mais de la sémantique....

Qu'est-ce que vous appelez "couche physique" ? Pour moi, "couche physique", c'est le niveau 1 dans le modèle OSI et cela concerne les réseaux : https://fr.wikipedia.org/wiki/Mod%C3%A8le_OSI
Cela ne traite pas de la sémantique mais juste un classement des caractères. Voir §6 ci-après : https://fr.wiktionary.org/wiki/collation

Code :

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

1
2
6. (Bases de données) Règle de classement des caractères.
Une collation est une énumération de signes typographiques avec leurs équivalences, afin d’en déduire le comportement des chaînes de caractères notamment dans les opérations de comparaison et de tri spécifiques à une langue. — (Frédéric Brouard, Rudi Bruchez, Christian Soutou, SQL, Pearson Education France, 13 juillet 2012)

Et vous utilisez à tort le sens de "sémantique" : https://fr.wikipedia.org/wiki/S%C3%A9mantique

Code :

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

La sémantique est une branche de la linguistique qui étudie les signifiés, ce dont on parle, ce que l'on veut énoncer

Donc la collation sert au tri qui est spécifique à une langue et plus précisément des règles typographiques.

Il est temps de recentrer le débat sur :

Entièrement d'accord avec toi. Vu que je n'ai jamais fait cela, j'ai fait une recherche sur le net pour comprendre ce qui se faisait ailleurs.
Ce sujet est mal compris et il y a autant de solutions qu'il existe d'opinion sur ce sujet. Et encore, je n'aborde même pas le problème des collations.

Le découpage est fait à partir de la langue. Je veux bien. Mais quand est-il des particularités propre à un pays ?
Le français de France n'est pas le français de Suisse ou de Belgique et encore moins du Canada.
Doit-on plutôt faire un découpage en fonction du pays ? Oui, mais alors on a beaucoup de redondance. Mais comment gérer la redondance ?
Il faudrait définir une langue de référence, et par pays ajouter les particularités. Ce qui va complexifier la base de données.

Voici en gros les questions que je me pose.

@+

[BFMic]

Merci. Je vais me servir de cette discussion pour expliquer à mes élèves ce qu'est l'orgueil et l'égo . Au moins ça servira à ça