Base de données et site multilingue

Version imprimable

23/01/2016, 12h09
PIEPLU

Base de données et site multilingue

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
26/01/2016, 16h06
SQLpro

Citation:

Envoyé par 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

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 +

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:

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:

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:

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:

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:

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 ;)

26/01/2016, 17h11
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
27/01/2016, 03h03
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:

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.

Citation:

Envoyé par 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.

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.

Citation:

Envoyé par al1_24

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.

Citation:

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.

Citation:

Envoyé par PIEPLU

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.

@+
28/01/2016, 10h08
SQLpro

1 pièce(s) jointe(s)
Citation:

Envoyé par Artemus24

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 !
Pièce jointe 199317
Comme montré dans l'image, la fonction SUBSTRING parcours à l'envers les caractères arabes...

Citation:

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.
Citation:
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:

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 !

Citation:

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 !

Citation:

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 +
28/01/2016, 13h40
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 :(
28/01/2016, 23h00
Artemus24

Salut SQLPRO.

Citation:

Envoyé par 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.

Citation:

Envoyé par SQLPRO

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.

Citation:

Envoyé par SQLPRO

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.

Citation:

Envoyé par SQLPRO

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.

Citation:

Envoyé par SQLPRO

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 !

Citation:

Envoyé par SQLPRO

Là viennent les bonnes questions...

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

Citation:

Envoyé par 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)

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 !

Citation:

Envoyé par Escartefigue

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".

Citation:

Envoyé par Escartefigue

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.

@+
29/01/2016, 09h05
escartefigue

Citation:

Envoyé par 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 :(

Citation:

Envoyé par Artemus24

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

Citation:

Envoyé par Artemus24

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

Citation:

Envoyé par Artemus24

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)
29/01/2016, 18h46
Artemus24

Salut Escartefigue.

Citation:

Envoyé par 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 ! :D

Citation:

Envoyé par escartefigue

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.

Citation:

Envoyé par escartefigue

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.

@+
29/01/2016, 19h19
SQLpro

2 pièce(s) jointe(s)
Citation:

Envoyé par Artemus24

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...

Citation:

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 :::

Citation:

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 :
Pièce jointe 199460
Pièce jointe 199461

Citation:

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 !

Citation:

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...

Citation:

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 !

Citation:

[...]

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 +

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:

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:

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:

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 +

30/01/2016, 11h39
Artemus24

Salut SQLPRO.

Citation:

Envoyé par 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.

Citation:

Envoyé par SQLPRO

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.

Citation:

Envoyé par SQLPRO

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.

Citation:

Envoyé par SQLPRO

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

Citation:

Envoyé par SQLPRO

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.

@+
01/02/2016, 10h21
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 !

Citation:

Envoyé par Artemus24

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/

Citation:

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)

Citation:

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 ?

Citation:

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) !

Citation:

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....

Citation:

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 +
01/02/2016, 10h56
escartefigue

Il est temps de recentrer le débat sur :

Citation:

Envoyé par 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

Salut SQLPRO.

Citation:

Envoyé par 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.

Citation:

Envoyé par SQLPRO

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".

Citation:

Envoyé par SQLPRO

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.

Citation:

Envoyé par SQLPRO

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.

Citation:

Envoyé par SQLPRO

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.

Citation:

Envoyé par SQLPRO

Recyclez vous !

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

Citation:

Envoyé par SQLPRO

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.

Citation:

Envoyé par SQLPRO

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.

Citation:

Envoyé par SQLPRO

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:

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:

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.

Citation:

Envoyé par Escartefigue

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.

@+

31/03/2020, 20h11
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 :P