Discussion :

[vica6a]

Salut à tous,

je possède en site couplé avec un forum phpbb. La base de données du tout fait à ce jour 660 Mo.
Le site fait entre 15 et 20k visiteurs unique par jour et donc la base est en constante augmentation.

Je suis en train d’internationaliser le site, et donc voici mon probleme.

La bdd héberge des images dans différentes catégories ET le forum et ses utilisateurs.
Pour l’internationalisation en anglais, je dois impérativement récupérer les tables "image" et "categorie". Il serait également pratique de travailler avec la meme table user.
Le soucis est que je souhaite recréer un second forum, et donc duppliquer chacune des tables phpbb, et je ne sais pas s'il sera plus interessant de faire ca dans la meme base, ou bien de créer une seconde base uniquement pour l'anglais, mais tout de meme un lien vers les tables image et categorie de la premiere base.

Est il plus rentable d'ouvrir deux bases en une seule page ? Ou bien de surcharger une seule base.. ?

En allant plus loin, imaginons que je veuille un jour traduire en italien, espagnol, ukrainien ... (ce qui aurait tres peu de chance d'arriver...), je risquerais de me retrouver avec une base ayant des centaines de tables, et pesant quelques Go...

Je tourne sur serveur privé.

D'avance, je vous remercie de me dire ce qu'il serait le plus interessant dans mon cas.

Edit : Pour aller plus loin, la table phpbb_posts fait actuellement 350Mo, jusqu'ou pensez vous que je puisse aller pour garder de bonnes performances ? Celà m'éviterais de créer un second forum parallèle...

[vica6a]

Sans votre aide, je suis au point mort... juste une piste ? Un avis serait le très bien venu

Merci

[SQLpro]

Bien entendu il ne faut pas créer une base par langue... Il faut en revanche que vos types littéraux soient dasn un encodage supportant UNICODE (donc du NCHAR et deu NVARCHAR...)

Mais la question fondamentale à se poser est justement la question des langues de votre internationalisation....
Parce que si vous envisagez des langues exotiques (non latines) par exemple, se pose la question du sens de lecture (de droite à gauche pour l'hébreu et l'arabe... - de haut en bas pour la calligraphie chinoise et japonaise...) et donc des collations qu'il faudra gérer, ne serait-ce que pour les tris et les recherches...

Et là en cette matière il y a peu de SGBDR qui les gèrent correctement !

• Oracle utilise une horreur appelé NLS et pas les collations
• SQL Server implémente plus de 3000 collations répondant à la plupart des langues de la planète et certains dialecte (par exemple Corse et Breton...).
• PostGreSQL implémente très peu de collations et certains module externe censé pallier le défaut provoquent des lenteurs inacceptables dans les requêtes
• MySQL : les collations sont pauvres, foutoir et buguées...

À me lire :
http://sqlpro.developpez.com/cours/s...age=partie1#L4
http://sqlpro.developpez.com/cours/s...er/collations/
http://blog.developpez.com/sqlpro/p1..._grand_folklor

A +

[vica6a]

Bonjour et merci pour votre réponse.
J'ai peut être du mal m'exprimer, mon problème n'est pas l'encodage, je compte de toute facon traduire uniquement en anglais pour l'instant.

Le réel probleme est selon moi la taille potentielle de la base de données si le forum "anglais" venait à prendre de l'ampleur. Ma base fait actuellement plus de 600Mo sous mysql avec la table des posts de 350Mo, et je n'ai aucune idée de la limite de taille avant que le serveur soit saturé... ?

Quoi qu'il en soit, je vais choisir de tout laisser sur la meme base, et je verrais bien jusqu'ou le serveur peut aller !

Merci.

[ddoumeche]

600Mo cela ne me semble pas beaucoup, il y a de la marge mais si tu as l'impression que ton site est lent, il faudrait optimiser les requetes lentes justement... ou peut-être envisager de stocker les images sur le disque, elles seraient plus rapidement servies et cela soulagerait le sgbd.
Surtout que les serveurs web délèguent souvent l'envoi des fichiers statique au kernel.

Une autre possibilité est de faire une partitionnement de bases par langue ou pays comme tu le suggérais, avec une réplication des tables communes (users, catégories, etc...) entre ces bases, voir entre serveurs.
Mais en l'état cela me semble démesuré