Discussion :

[redah75]

Bonjour tout le monde.
j'aurais 4 petites questions a vous poser qui paraitront surement simples pour certains... mais qui m'empechent d'avancer

1- je suis entrain de creer un site qui sera en plusieurs langues. de ce fait, j'ai crée une table speciale pour les civilités:

Code :

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

1
2
3
4
5
6
7
8
9
10
civilites:
-----------------------------------------------------
id_civilite (SMALLINT, PRIMARY, Auto Increment)
 
civilites_traductions:
-----------------------------------------------------
id_civilite (SMALLINT, INDEX)
lang (INDEX)
libelle_court (VARCHAR 5)
libelle (VARCHAR 20)

ce qui me gene est la table "civilite" est ce correcte et bon d'avoir un seul champ dans cette table??

2- est il conseillé d'utiliser des identifiants pour les langues et pays ou plutot leur code ISO (fr, en es)??

3- lors de la creation des tables, faut il toujours mettre en INDEX les champs qui representent une cle etrangere ??

4- et enfin, est il conseillé d'utiliser des tirets (-) ou underscore (_) dans la bdd mysql ?? car j'avais entendu dire que les - sont deconseillés!!

Merci infiniment
Reda

[Maljuna Kris]

Saluton,

Outre ces index, tu dois définir le couple id_civilite, lang comme UNIQUE dans la table civilites_traductions.
Il vaut effectivement mieux éviter les tirets dans les noms de colonnes, de tables, de bases, d'index etc...
Pour le point 2, si tu te réfères au contenu de la colonne `lang`, il peut être pertinent d'utiliser une nomenclature internationale standard.
Les civilités étant, que je sache, une nomenclature fermée et invariante ( Mme, Mle, M.) je verrais plutôt une colonne ENUM qu'une table qui ne comportera jamais que 3 lignes.

[redah75]

Bonjour Kris et merci bp pour ta reponse.

Outre ces index, tu dois définir le couple id_civilite, lang comme UNIQUE dans la table civilites_traductions.

meme si les valeurs se repetent je dois mettre ces 2 champs en UNIQUE??

Pour le point 2, si tu te réfères au contenu de la colonne `lang`, il peut être pertinent d'utiliser une nomenclature internationale standard.

je devrais garder l'utilisation de 'fr', 'en' pour les langues et 'FR', 'ES', 'UK' pour les pays alors si j'ai bien compris??

Les civilités étant, que je sache, une nomenclature fermée et invariante ( Mme, Mle, M.) je verrais plutôt une colonne ENUM qu'une table qui ne comportera jamais que 3 lignes.

excuse moi mais j'ai pas bien compris. c'est vrai qu'il y aura toujours que 3 civilités mais en plusieurs langues. quelle structure de table preconises tu?

j'aurais 2 autres petites questions

1- ma page web ainsi que ma bdd sont declarées en utf8. lorsque j'insere un caractere accentué (é) il m'insere "é" est ce correcte ou faut il plutot avoir "é" ?

2- pour inserer des caracteres avec apostrophes, mieux vaut il utiliser addslashes dans la requete SQL ou plutot mysql_real_escape_string ??

Merci Merci mille fois

[Maljuna Kris]

meme si les valeurs se repetent je dois mettre ces 2 champs en UNIQUE??

L'index associé à ces deux champs accouplé doit être UNIQUE

je devrais garder l'utilisation de 'fr', 'en' pour les langues et 'FR', 'ES', 'UK' pour les pays alors si j'ai bien compris??

Tu peux ne garder qu'une nomenclature et utiliser UPPER() ou LOWER()

excuse moi mais j'ai pas bien compris. c'est vrai qu'il y aura toujours que 3 civilités mais en plusieurs langues. quelle structure de table preconises tu?

Ce que je veux dire c'est que la clé étrangère composée du code de civilité (1, 2 ou 3) plus du code de langue permet de retrouver le libellé court ou long dans la langue souhaitée. La table civilités ne sert donc à rien

j'aurais 2 autres petites questions

1- ma page web ainsi que ma bdd sont declarées en utf8. lorsque j'insere un caractere accentué (é) il m'insere "é" est ce correcte ou faut il plutot avoir "é" ?

2- pour inserer des caracteres avec apostrophes, mieux vaut il utiliser addslashes dans la requete SQL ou plutot mysql_real_escape_string ??

Pour ces deux derniers points il y a, de mémoire, d'excellentes pistes dans la FAQ. L'utilisation des entités HTML n'est point sotte en soi, mais elle ne permettra plus les recherches et/ou indexations textuelles.

[CinePhil]

Comme Maljuna Kris, je trouve que la table 'civilites' ne sert à rien.

Pour ta table 'civilites_traductions', fais du couple {lang, id_civilite} ta clé primaire et ajoute éventuellement un index séparé sur id_civilite. Encore que ce dernier ne soit peut-être jamais utilisé car il ne contiendra que très peu de valeurs différentes et le SGBD l'ignorera probablement.

Quant à 'lang', c'est normalement une clé étrangère faisant référence à l'identifiant de la table des langues (ou des pays). Il faudrait donc que cet identifiant soit de type char(2) comme ici. Ce n'est pas forcément optimum. À partir de VARCHAR(3) ou CHAR(4) autant prendre un type entier qui occupe la même place et est traité plus rapidement par le SGBD. Et en MySQL, je crois que SMALLINT n'occupe que 2 octets soit l'équivalent d'un CHAR(2).

[redah75]

Bonjour Maljuna Kris et CinePhil et grand merci pour vos reponses.

Tu peux ne garder qu'une nomenclature et utiliser UPPER() ou LOWER()

selon ce que CinePhile a dit, je suis a present tres confus et je ne sais toujours pas si je dois utiliser des identifiants de type SMALLINT ou des identifiants en CHAR(2) qui contiendra le code ISO du pays ou la langue!!
CinePhile: tu dis que le type CHAR n'est pas optimum et n'est pas aussi rapide qu'un INT. est ce considérable comme difference??

Comme Maljuna Kris, je trouve que la table 'civilites' ne sert à rien.

OK, je supprimerai la table civilité et garder que civilite_traductions:

Code :

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

1
2
3
4
5
6
1	en	Mr	Mister
2	en	Mrs	Mrs
3	en	Miss	Miss
1	fr	M.	Monsieur
3	fr	Mlle	Mademoiselle
2	fr	Mme	Madame

est ce correcte comme structure??

Pour ces deux derniers points il y a, de mémoire, d'excellentes pistes dans la FAQ. L'utilisation des entités HTML n'est point sotte en soi, mais elle ne permettra plus les recherches et/ou indexations textuelles.

Crois moi j'ai bien cherché mais j'ai rien trouvé a ce sujet, du moins rien de pertinent. je suis preneur si tu as des liens...
mais ce que je veux savoir est simple, faut il inserer 'é' ou 'é' ou 'é' pour la lettre 'é'

Merci encore une fois pour votre aide!

[Maljuna Kris]

Crois moi j'ai bien cherché mais j'ai rien trouvé a ce sujet, du moins rien de pertinent. je suis preneur si tu as des liens...
mais ce que je veux savoir est simple, faut il inserer 'é' ou 'é' ou 'é' pour la lettre 'é'!

Cet excellent article d'Antoun, par exemple

[redah75]

Cet excellent article d'Antoun, par exemple

Merci pour le lien tres interessant.
au moment de la creation de la base de donnée ainsi que ses tables, j'ai toujours choisi utf8_unicode_ci mais malgré cela, lorsque j'insere des caracteres accentués depuis un formulaire, il me les transforme en leur equivalents... je pense que cela n'est pas normal!! que faut il faire?

aussi lorsque je clique sur le nom de ma base de donnees dans pma, il m'affiche toutes mes tables qui ont toutes le type innoDB mais dans la derniere ligne (sum) il m'affiche MyISAM, est ce normal?

[redah75]

bonjour, de retour pour une toute derniere question
est il utilse d'avoir les civilités dans une base de donnees?? ne serait il pas interessant de les avoir tout simplement dans un fichier texte de traduction??

[CinePhil]

au moment de la creation de la base de donnée ainsi que ses tables, j'ai toujours choisi utf8_unicode_ci mais malgré cela, lorsque j'insere des caracteres accentués depuis un formulaire, il me les transforme en leur equivalents... je pense que cela n'est pas normal!! que faut il faire?

C'est un problème classique de correspondance de pages de codes entre le programme et le SGBD. Si tu développes en PHP et que tu fais une recherche sur "PHP MYSQL lettres accentuées", tu trouveras sûrement plein de liens et de tutoriels. J'ai moi-même pas mal galéré la-dessus en utilisant le Zend Framework et j'avais créé au moins une discussion dans le forum correspondant.

aussi lorsque je clique sur le nom de ma base de donnees dans pma, il m'affiche toutes mes tables qui ont toutes le type innoDB mais dans la derniere ligne (sum) il m'affiche MyISAM, est ce normal?

Oui c'est classique mais ça n'a pas d'importance. C'est peut-être dû au fait que le moteur par défaut du SGBD est MyISAM. Peut-être que si tu changes la valeur de la variable storage_engine ça te mettra InnoDB dans la ligne Total ?

est il utile d'avoir les civilités dans une base de donnees?? ne serait il pas interessant de les avoir tout simplement dans un fichier texte de traduction??

Si la BDD est grosse et que les traitements doivent être faits sur un grand nombre de données à la fois, le SGBD sera plus rapide qu'un programme externe pour faire la traduction. Il ne faut pas avoir peur des jointures, les SGBD sont faits pour ça !

[redah75]

C'est un problème classique de correspondance de pages de codes entre le programme et le SGBD. Si tu développes en PHP et que tu fais une recherche sur "PHP MYSQL lettres accentuées", tu trouveras sûrement plein de liens et de tutoriels. J'ai moi-même pas mal galéré la-dessus en utilisant le Zend Framework et j'avais créé au moins une discussion dans le forum correspondant.

la soultion et de rajouter mysql_query("SET NAMES 'utf8'"); avant le mysql_select_db()

Oui c'est classique mais ça n'a pas d'importance. C'est peut-être dû au fait que le moteur par défaut du SGBD est MyISAM. Peut-être que si tu changes la valeur de la variable storage_engine ça te mettra InnoDB dans la ligne Total ?

au fait storage_engine de TOUTES mes tables est en InnoDB, je ne vois pas ce qui ne va pas!!

Si la BDD est grosse et que les traitements doivent être faits sur un grand nombre de données à la fois, le SGBD sera plus rapide qu'un programme externe pour faire la traduction. Il ne faut pas avoir peur des jointures, les SGBD sont faits pour ça !

dans mon cas il s'agit juste des civilités (masculin, feminin) qui sera en plusieurs langues, j'aurai aussi une autre table qui sera type d'adresse (facturation, livraison) mais je me demande si ca vaut le coup d'avoir une table pour 2 valeurs quis seront en plusieurs langues...

[CinePhil]

la soultion et de rajouter mysql_query("SET NAMES 'utf8'"); avant le mysql_select_db()

Effectivement oui, je m'en souviens maintenant que tu le dis.

au fait storage_engine de TOUTES mes tables est en InnoDB, je ne vois pas ce qui ne va pas!!

Je parlais du paramètre global de MySQL. Pas de l'engine de chaque table.

dans mon cas il s'agit juste des civilités (masculin, feminin) qui sera en plusieurs langues, j'aurai aussi une autre table qui sera type d'adresse (facturation, livraison) mais je me demande si ca vaut le coup d'avoir une table pour 2 valeurs quis seront en plusieurs langues...

Le problème, ce n'est pas la table à 2 valeurs en plusieurs langues, c'est la jointure avec la table des personnes. Si celle-ci fait par exemple 1 million de lignes, la jointure sera beaucoup plus rapide à mon avis que de faire traiter par ton programme la traduction de la civilité 1 million de fois.

[redah75]

wow, encore une fois, je n'ai recu aucune notification pour ta reponse!!

Je parlais du paramètre global de MySQL. Pas de l'engine de chaque table.

ah d'accord, mais je ne vois pas trop ou se trouve ce parametre!!

Le problème, ce n'est pas la table à 2 valeurs en plusieurs langues, c'est la jointure avec la table des personnes. Si celle-ci fait par exemple 1 million de lignes, la jointure sera beaucoup plus rapide à mon avis que de faire traiter par ton programme la traduction de la civilité 1 million de fois.

oui oui je vois ce que tu veux dire, mais dans ce cas precis, j'aurais au maximum une 20ene de valeurs, ce qui veux dire que mon site est en 10 langues et ca ne sera pas pour demain, ni l'annee prochaine ni la suivante
ma table pour l'instant contient 4 lignes: homme & femme pour le francais et male & female pour l'anglais. je penais donc attribuer par example 1->male & homme puis dans mon fichier xml de traduction j'aurais une variable civility_1 = Male ou Homme selon la langue du fichier

la meme chose pour le type d'adresse: Livraison & facturation

qu'en penses tu?

[CinePhil]

Ça veut dire que tu vas devoir :
- Extraire les données à afficher avec le code du sexe (1 ou 2) ;
- Mettre le sexe dans une variable du programme ;
- Lire un fichier XML ;
- Mettre en correspondance la variable avec le fichier XML pour afficher dans la bonne langue, laquelle sera probablement déterminée elle aussi par une autre variable.

Dans la modélisation normalisée, si la langue est celle de l'utilisateur, tu construis ta requête en fonction de cette langue en ajoutant une restriction dans le WHERE et tu récupères en une seule requête avec jointure les données sexuées depuis la BDD.
De plus tu n'auras jamais à modifier ton code ni aucun fichier XML si tu ajoutes une langue. Il te suffira d'ajouter des données dans une table.

------------------

Pour le paramètre global de MySQL, si tu as phpMyAdmin, en haut de l'écran tu clique sur Serveur : tonserveur puis tu sélectionne l'onglet Variables. Ça t'affiche toutes les variables globales de MySQL dont celle citée précédemment.
pour voir comment la modifier, voir la doc MySQL.

[redah75]

Ça veut dire que tu vas devoir...

je serai bien obligé d'appeler un fichier de traduction .xml pour afficher les autres textes du site web, donc 2 ou 3 variable en plus ne changera pas grand chose!!
lorsque le site doit etre traduit en espagnol par exemple, il faudrait traduire la bdd et aussi les fichiers xml...
je fais actuellement de meme pour les mois et jours de semaines.
en gros, tout ce qui ne change pas, c'est a dire les infos qui n'auront pas d'enregistrements suplementaires je le mets dans le fichiers de traduction...
comme par exemple les jours de semaines, il n'y aura jamais de 8e jours

concernant mysql, je ne peux pas cliquer sur "server: nom serveur" j'ai la version 3.3.4, voici ce qui est affiché mais non cliquable:

MySQL
Server: Localhost via UNIX socket
Server version: 5.1.48
Protocol version: 10
User: root@localhost
MySQL charset: UTF-8 Unicode (utf8)