Une Bdd mysql par langue

[jerome72]

Bonjour,

Je suis entrain de créer un site traduit en francais, anglais et italien.
Pour gérer ces trois langues, j'ai créé une base de données par langue, chacune des trois bases ayant la meme structure. J'utilise des variables de session pour identifier la langue en cours.

Je voudrais savoir si ma méthode est bonne : cela peut-il poser des problèmes d'avoir sur le même site des connexions à plusieurs bases de données, en termes de ressources / performances ?

Merci d'avance
Jerome

 

[finstreet]

pourquoi tu ne rajoutes pas juste un champ Langue pour les tables où il y a du contenu ?

 

[dmathieu]

Multiplier les bases de données est très lourd.
Comme le dit finstreet, une seule db avec un champ "langue" serait beaucoup plus adapté.

 

[jerome72]

Merci pour vos réponses!

Pourquoi est-ce plus lourd de multiplier les bases ?

 

[e-kiwi]

ou gere ca en tables :

fr_table1
fr_table2
fr_table3

en_table1
en_table2
en_table3

...

 

[jerome72]

Bonjour,

Je suis d'accord sur le principe de créer une table par langue.

Mais je souhaite vraiment savoir en quoi il est déconseillé de gérer cela dans plusieurs bases. Cela peut-il poser des problemes en termes de ressources ou de performances, et si oui pour quelle raison?

Merci d'avance

 

[dadovb]

Si ton utilisateur change de langue, il va falloir que tu te déconnecte d'une database, pour te connecter à une autre, et ainsi de suite à chaque changement de langue.

C'est beaucoup plus léger en termes de ressources de changer de table que de base.

Tu peux même ne pas avoir à changer de table mais juste de champ, exemple :

Table : news
Attributs : id, Date, texte_fr, texte_en, texte_ita, etc....

Comme ca tu gère simplement l'affichage de la bonne langue comme ca :

"SELECT date, texte_$lang FROM news;"

 

[e-kiwi]

>> Si ton utilisateur change de langue, il va falloir que tu te
>> déconnecte d'une database, pour te connecter à une
>> autre, et ainsi de suite à chaque changement de langue.

je ne comprend pas, a chaque requete on se connecte à la base, donc en quoi cela est-il génant de se conencter à des bases differentes à chaque requete ?

 

[dmathieu]

Pas daccord. Il est plus optimisé de se connecter une seule fois. ça évite des multiples transferts inutiles de données (et maintiens un socket activé plus longtemps, mais à moins que tu n'ait un sleep() qui dire une minute, c'est dérisoire)

Par contre, la raison de dadovb n'est pas correcte dans le sens ou en changeant de langue, tu recharge la page. Et là, de toute façon, tu te reconnecte.

De mon point de vue, il vaut mieux faire des champs "langue" sur une seule dbcar lorsque tu fait une modification dans ta db ou ton code, elle est répercutée partout. tu n'a pas de problèmes d'erreur suite à un oubli d'ajout d'un champ dans une autre langue.

Et d'un point de vue mémoire, il vaut mieux n'avoir qu'un seul gros fichier que plein de petits (ca permet plus difficilement de s'y retrouver lorsque c'est textuel. mais là, ca ne l'est pas. c'est une db)

 

[e-kiwi]

pas daccord, tu multiplie les chances d'avoir du max_user_connection en gardant ta BDD ouverte durant toute l'execution du script, le conseil d'ouvrir et fermer la connexion à chaque requete vient de mon hebergeur qui lui préconise àa

 

[jerome72]

Si ton utilisateur change de langue, il va falloir que tu te déconnecte d'une database, pour te connecter à une autre, et ainsi de suite à chaque changement de langue.

C'est effectivement le cas, mais je ne comprend pas bien pourquoi c'est plus lourd en termes de ressources, ou alors j'ai du mal coder ma connexion aux bases.

J'ai un fichier connexion.php, header.php et index.php
Le header.php (qui contient l'entete de la page HTMl) fait un include("connexion.php").
Le connexion.php crée la connexion et la selection de la base.
A chaque rafraichissement de page, et a chaque fois que l'on clique sur un lien, le header.php est appelé, qui appelle lui-même le connexion.php
Alors, qu'il n'y ait qu'une seule base ou plusieurs, j'ai du mal a saisir quelle différence il y a puisque même avec une seule base il y a a chaque fois une nouvelle connexion. Pour résumer, meme si on est connecté à la base, dés qu'on clique un lien, on s'y reconnecte de suite...
Peut etre que ma méthode de connexion exprimée ci-dessus est mauvaise ??

 

[rog]

moi j'aime bien le système en multi base

si chaque base contient l'intégralité des données pour une langue et qu'il n'ya pas besoin de se connecter à une autre pour rechercher des infos

il n'y a que des avantages :

1 le changement de langue se fait juste par le changement de config d'acces à la base

2 ça permet de cloisonner les modifs par traducteur

rog

 

[dmathieu]

[quote="e-kiwi]pas daccord, tu multiplie les chances d'avoir du max_user_connection en gardant ta BDD ouverte durant toute l'execution du script, le conseil d'ouvrir et fermer la connexion à chaque requete vient de mon hebergeur qui lui préconise àa[/quote]
Et ta solution est plus consommatrice en ressources vu que tu déconnecte et reconnecte un socket à chaque requete. Chacune a ses avantages & inconvénients. Mais excepté en mutualisé ovh, les problèmes de max_user_connection n'arrivent jamais (tous mes sites fonctionne comme cela par ailleurs)

 

[dadovb]

Pour résumer, meme si on est connecté à la base, dés qu'on clique un lien, on s'y reconnecte de suite...
Peut etre que ma méthode de connexion exprimée ci-dessus est mauvaise ??

Tu ne referme pas tes connexions, une fois ta requete traitée ?

Sinon, comme a dit, je sais plus qui juste au-dessus, le principal désavantage de plusieurs databases, ca va etre quand tu vas faire des modifs : rajouter / supprimer des champs, il faudra le faire dans chaque database.

 

[dadovb]

Par contre, la raison de dadovb n'est pas correcte dans le sens ou en changeant de langue, tu recharge la page. Et là, de toute façon, tu te reconnecte.

Effectivement, il est temps que j'arrete de dire des conner*es, je vais me recoucher.

 

[finstreet]

Merci pour vos réponses!

Pourquoi est-ce plus lourd de multiplier les bases ?

Pour moi plusieurs choses

- Si il s'agit du meme contenu et que tu as des tables uniquement de jointure... ca n'a aucun intéret de les dupliquer... tu risques meme les erreurs
- quand tu mets à jour une base, tu n'en as qu'une à mettre à jour... toi tu en as 5

Bref tu multiplies les erreurs possibles de manipulation sans réel intéret

 

[e-kiwi]

2 écoles s'affrontent pour moi tu dois fermer ta connexion à chaque BDD? surtout si ton nombre d utilisateurs connectés maximum est faible (moins de 10).
faudrait voir les caracteristiques de ton hébergeur

 

[jerome72]

Tu ne referme pas tes connexions, une fois ta requete traitée ?

Non je devrais?

Par exemple mettre un mysql_close(); dans un footer.php ?

Je vois que vos avis divergent un peu sur la question des multi-bases...
Fondamentalement, a part la gestion des bdd, coté performances/ressources, il n'y a pas vraiment de problème?

 

[e-kiwi]

contacte ton hebergeur pour savoir si il preconise l'ouverture / fermeture de la connexion à chaque requete ou si il préconise l'ouverture en debut de page et la fermeture en fin de page

 

[jerome72]

Pour moi plusieurs choses

- Si il s'agit du meme contenu et que tu as des tables uniquement de jointure... ca n'a aucun intéret de les dupliquer... tu risques meme les erreurs
- quand tu mets à jour une base, tu n'en as qu'une à mettre à jour... toi tu en as 5

Bref tu multiplies les erreurs possibles de manipulation sans réel intéret

finstreet, je pense que tu touches au fond du problème : pourquoi faire simple quand on peut faire compliqué, lol !
Je pense donc que je vais suivre vos conseils, et n'adopter qu'une seule base, cela semble plus sage, plus propre, plus facile a maintenir, etc
En tous cas merci à tous pour vos contributions qui m'ont bien éclairé !

 

[dadovb]

Et pense à fermer ta connexions, dans le footer ou juste après avoir récupérer tes infos.

 

[jerome72]

Et pense à fermer ta connexions, dans le footer ou juste après avoir récupérer tes infos.

Est-ce vraiment utile, vu que la connexion est automatiquement fermée a la fin du script (sauf si on utilise des connexions persistentes) ?

 

[rog]

les ecoutes pas

une base par langues est la strategie la plus correcte à adopter

rog

 

[dadovb]

L'idéal selon moi en théorie et tant que c'est possible (en dehors de gros projets avec architectures MVC, n-tiers et cpnie...) :

(je te le fais comme l'algorythmique des DUT info )

connexion à la base;

requete;

recup des infos ds variables php;

fermeture connexion;

traitement variables;

affichage résultats;

Il faut que la connexion soit la plus courte possible dans le temps, et il ne faut en avoir qu'une seule à la fois par client.

 

[rog]

clair net et precis

bravo

rog

 

[dadovb]

les ecoutes pas

une base par langues est la strategie la plus correcte à adopter

rog

Niveau maintenance et évolutivité c'est pas génial...

 

[rog]

aie

desaccord potentiel

Niveau maintenance et évolutivité c'est pas génial...

peux tu developper ?

moi j'ai donné deux arguments

- cloisonner les acces db par traducteur/redacteur
- facilité de permutation des langages en ne renseignant que le chemin d'un fichier config d'acces db

rog

 

[finstreet]

Et pense à fermer ta connexions, dans le footer ou juste après avoir récupérer tes infos.

Est-ce vraiment utile, vu que la connexion est automatiquement fermée a la fin du script (sauf si on utilise des connexions persistentes) ?

Fais des tests... prend toi une page... calcul le temps de chargement en millisecondes... et remonte ensuite ton mysql_close dans ta page... et tu verras que bizarrement, le temps diminuera

 

[rog]

c'est clair car tu depend du time out

rog

 

[dadovb]

aie

desaccord potentiel

Niveau maintenance et évolutivité c'est pas génial...

peux tu developper ?

moi j'ai donné deux arguments

- cloisonner les acces db par traducteur/redacteur
- facilité de permutation des langages en ne renseignant que le chemin d'un fichier config d'acces db

rog

Prenons l'exemple que j'ai donné :

Une table 'news' avec comme attributs : ( id, date, texte_fr , texte_en, texte_it )

(Donc je pars du principe qu'il y a une seule database et une seule table par entité, les langues étant gérées par les champs "champ_lang" de chaque table)

S'il veut rajouter un attribut "titre" sur son entité 'news' , avec mon exemple, il y aura juste à rajouter un champ dans cette table.

Avec plusieurs database, il faudra faire la manip pour les n databases (n nombre de langues du site).
Avec une table par langue (news_en, news_fr, news_it ...), il faudra ajouter le champ aux n tables.
CQFD.

De plus, s'il veut ajouter une ou plusieurs langues, il suffira d'ajouter un champ à la table. S'il veut rajouter l'espagnol, il rajoutera le champ "texte_es".
Il n'y aura plus qu'à mettre en place une petite interface en backoffice pour que le traducteur face son boulot.

Voilou.

 

[rog]

c'est un argument valable

néanmoins son poids est relatif :

1) on ne retouche pas une table toutes les 5 minutes (c'est une source de corruption de table)
2) une commande et une boucle sur 100 bases et en 200 secondes j'ai updaté 100 bases différentes

différencier les bases :

1) une corruption de table n'entraine pas le bug sur toutes langues
2) une mauvaise manip dans l'update d'un texte ne peut affecter qu'une langue
etc ..

rog