Une ou plusieurs BDD ?

[Zappada]

Bonjour à tous !

Je suis en train actuellement de restructurer mon jeu pour augmenter sa fluidité au maximum et pouvoir encaisser plus de fonctionnalités et plus de calculs, et je me posais une question :

Est-ce qu'utiliser plusieurs bases de données permet d'avoir une meilleure fluidité ou alors justement ça change rien ?

En fait, si tel était le cas, je souhaiterai structurer mes données plus ou moins ainsi :

-Une base de données contenant toutes les valeurs inchangeables du jeu, comme les caractéristiques des matériels, les différents paramètres me concernant pour gérer le jeu, etc. Pourquoi pas aussi dans celles là les données des joueurs
-Une base de données contenant les informations qui bougent. Dans le cas où j'ai un jeu sur l'aéronautique, par exemple les vols en cours, les ventes en cours, les messages sur le forum, sur le chat du jeu. Et pourquoi pas ici aussi les données des joueurs, et les historiques de vols.
-Une troisième base de données que je réserverai uniquement aux "textes" du jeu. Je m'explique : Je veux créer un jeu multilingue, même si j'accueillerais p'tête jamais d'étrangers, juste comme ça, pour le plaisir ! Étant donné que chaque script va chercher à chaque exécution les différents textes en fonctions des langues, je pourrais leur réserver une base pour pas empiéter sur les autres !

Donc voilà, j'attends vos lumières sur ce sujet !

Merci d'avance !

[php_addict]

alors alors...tout dépend de ce que tu veut en fait...

une seule base joueur peut très bien se faire si tu as plusieurs mondes/univers et un seul compte joueur pour tout les univers...perso je déteste ca...car je préféré me réinscrire sur un autre monde avec un autre pseudo...ou alors faut pouvoir changer de pseudo selon les mondes tout en conservant son compte joueurs, bref, galere...c'est un vrai choix en fait

premièrement il faut que tu sache si tu aura plusieurs mondes/univers car ca complique l'architecture si tu separe tes bases

au niveau de la fluidité, je comprends pas bien ce que tu entends? rapidité? je dirais non, mysql peut encaisser pas mal de chose...

puis plusieurs bases sous entends plusieurs connexions vers elles, donc plusieurs singelton si tu utilise ce model

pour ce qui est des textes dans la base de donnée, c'est la pire des solutions, les textes doivent être dans tes fichiers vues uniquement (fichier php ou html donc...), 'fin la grosse majorité des textes je veut dire...

pour la traduction, bien que je n'ai pas encore mis cela en place c'est : http://php.net/manual/en/book.gettext.php (fin ca c'est pour php mais y a plusieurs supports differents...)

d'autres te donnerons des conseils de pro, pas d'autodidacte comme moi qui n'ai jamais fait d'etude en informatique ;-)

voili voilou

[niahoo]

Ben déjà les textes ça fait partie des données inchangeables donc je les mettrai avec les autres données inchangeables.

Puisque ces données ne changent pas, tu peux optimiser la base qui les contient pour être plus rapide en lecture au détriment de l'écriture.

Et pour toutes les données qui changent, c'est à dire celles des joueurs, optimiser pour avoir un compromis entre lecture et écriture.

Mais tout ça doit pouvoir se faire table par table sur un SGBDR tel que postgreSQL ou mySQL je suppose.

---

+1 pour getText en php

[Xenos]

Heu, perso, les données "quasi-statiques", genre les textes de localization (c'est à dire les textes du site), je ne les colle pas en BDD, pour plusieurs raisons:
- Cela oblige à se connecter à la BDD, ce qui n'est pas une bonne chose car le nombre de connexions simultané est limité
- Les données changent peu, les BDD sont plutôt faites pour ce qui change
- Les données prennent beaucoup de place

Je les case donc dans des fichiers XML, que je pré-traite pour en faire un fichier php qui contient des constantes (par exemple, mon xml contient le noeud "localization/fr/menu/connexion", dont la valeur est le texte du menu de connexion. Ensuite, je traite ce xml pour en faire un PHP dans lequel j'ai une constante (type "const localization_fr_menu_connexion, en pratique, j'utilise des namespaces, mais l'idée est la même).
Ainsi, si j'ai besoin de ce texte (donnée "quasi-"constante), je n'ai qu'à inclure le fichier php: c'est rapide, ca ne demande pas d'accès à la BDD, et c'est flexible (il suffit d'éditer le xml et de re-compiler le xml en php).

Pour en revenir aux BDD, je pense que ce n'est pas utile d'en avoir plusieurs, sauf si elles n'ont que de très rares communications entre elles, voire (idéalement), pas de communication du tout. En effet:
- Si la plupart des pages a besoin des deux bases de données, il faudra ouvrir deux connexions: c'est moins bien qu'une seule pour la page, et pour chacune des BDD, ca change rien, donc autant en avoir qu'une seule
- Si tu as besoin de faire de la maintenance, la question "zut, c'est dans quelle BDD au fait?" se posera vite et souvent
- De même, la question "flûte, c'est quoi le mot de passe?" reviendra

Ne fais plusieurs BDD que si les BDD ne communiquent pas entre elles.
Si tes données dépassent la limite de l'hébergeur, soit tu changes de formule pour un plus gros, soit tu réduis ta BDD, mais ne "split" pas sur 2 BDD dans ce cas. Idem pour des soucis de performances. Pour les performances, tu peux scinder en deux BDD si elles sont vues comme une seule. En d'autres mots, tu as 2 hardwares qui tournent, mais tu ne vois que 1 software: une seule connexion suffit à accéder à toute la BDD (je ne pense pas que tu sois dans ce cas).

[Zappada]

D'accord.

Donc je résume : Avoir plusieurs bases de données n'améliore en rien la fluidité de chargement, au contraire ça pose beaucoup de problèmes ! Donc j'oublie cette possibilité !

Maintenant j'aimerais revenir sur ce que vous m'avez dit sur les textes : En les enregistrant dans des fichiers textes plutôt (pour moi, à faire, c'est pareil, voir peut-être même plus simple), c'est une bonne idée ? Enregistrer dans des fichiers est-il plus rapide que dans une BDD ?

Tiens d'ailleurs je peux vous demander ce que vous pensez de mon système que j'ai fait :
En fait dans un premier temps, je créé mes pages normalement, en français, sans me poser des questions. Et une fois que toute une partie marche bien, que je l'ai bien rodée, je remplace mes textes (prenons un exemple, imaginons il y a un texte "Bienvenue ici, comme tous les jours, il y fait beau.") par une fonction que j'ai créée, sous cette forme :
echo 'Bienvenue ici, comme tous les jours, il y fait beau.'; remplacé par echo textes('Bienvenue ici, comme tous les jours, il y fait beau.');
Que contient la fonction textes()?
En fait dans un premier temps la fonction vérifie si la phrase dans la fonction existe déjà dans la base de données, si tel est le cas, il la remplace par son équivalent dans une langue (choisie auparavant par l'utilisateur), si la traduction a été écrite dans la langue concernée par un des traducteurs. Si la fonction ne trouve pas dans la table le morceau de texte, il l'enregistre dans une nouvelle ligne, et cette ligne va attendre bien sagement dans la table qu'un des traducteurs aille y faire la traduction (à l'aide d'une autre interface que j'ai bricolé) !
Ce système me permet de remodifier n'importe quel texte du site quand je veux, et de me soucier de la traduction que plus tard !

[niahoo]

Pour les textes en plusieurs langues, utilises gettext et poedit.

[php_addict]

http://php.net/manual/fr/function.gettext.php

mais cela suppose de compiler tes fichiers texte, c'est chiant... car quand tu modifie un texte tu est obligé de recompiler...

a priori c'est la solution la plus viable...si il y en a d'autre alors je suis également intéressé...

[niahoo]

poedit les compile.

[Zappada]

Ces fonctions ont l'air très intéressantes ! Merci beaucoup !

[Xenos]

En les enregistrant dans des fichiers textes plutôt (pour moi, à faire, c'est pareil, voir peut-être même plus simple), c'est une bonne idée ? Enregistrer dans des fichiers est-il plus rapide que dans une BDD ?

Non, mais dans le cas présent, l'enregistrement est rare, donc cela n'influera pas les performances. En revanche, si les fichiers sont compilés dans le langage-cible (php, ruby, etc), leur chargement sera bien plus rapide que de passer par la BDD.
Les fichiers textes, pourquoi pas, mais c'est non-sémantique (0 balisage).
les fichier PO/MO, pourquoi pas, je ne connais pas, donc je ne peux pas juger.
Le XML compilé ensuite en *.php a l'avantage d'être très souple (c'est du XML), sémantique (XML est balisé), poly-lingual (unicode possible sans soucis), à jour (le w3c s'en occupe), "translangage" (php, javascript, ruby, etc savent tous lire un xml, donc on peut l'y manipuler).
L'atout d'avoir un XML réside également dans la possibilité de faire traiter la traduction soit pas le serveur (j'ai un XML contenant les traduction, le serveur le compile en *.php, et s'en sert pour traduire la page AVANT de l'envoyer au client), ou par le client (un javascript va chercher le fichier XML de traduction, s'il n'a pas été modifié il n'est pas re-téléchargé car le navigateur l'a en cache, le javascript le lit grâce aux XMLHttpRequest et XMLResponse, et change les noms de localization par leur traduction dans la page une fois téléchargée).

Le principe est bon, néanmoins, tu peux probablement l'améliorer: au lieu de considérer que le texte d'origine (français) est traduis en d'autres langues, tu peux considérer que le concept de "texte" est "instancié" par une traduction, y compris le français. En ce cas, tu auras, dans la BDD, une table de type:

-Identifiant_concept_texte- -Identifiant_Langue- -Texte-

La première colonne est un identifiant du texte à afficher, la 2e est l'identifiant de la langue de la traduction, et Texte, le texte traduis. Si tu cherches la traduction d'un texte d'identifiant donné, tu le pioche dans ta table à partir du couple "identifiant du texte / identifiant de langue". Si l'entrée n'existe pas, tu te rabat sur une autre langue, "par défaut". Si elle n'existe pas non plus, tu prends la 1ere traduction disponible.


Dans mon cas, j'ai utilisé un système très similaire, basé sur XML/PHP, et détaillé dans le topic sur le stockage du texte hors des vues.