Article Centralisation et séparation des données - Version imprimable +- JeuWeb - Crée ton jeu par navigateur (https://jeuweb.org) +-- Forum : Discussions, Aide, Ressources... (https://jeuweb.org/forumdisplay.php?fid=38) +--- Forum : Programmation, infrastructure (https://jeuweb.org/forumdisplay.php?fid=51) +--- Sujet : Article Centralisation et séparation des données (/showthread.php?tid=8216) |
Centralisation et séparation des données - Xenos - 14-09-2020 Centralisation et séparation des données Aide concernant ce tuto Introduction L'objectif de ce tutorial est d’éviter l'erreur classique d'insérer des données dans du traitement. Il montre à l'aide d'un exemple les problèmes engendrés par cette erreur et donne quelques solutions. Pourquoi centraliser les données? Un jeu par navigateur représente souvent une quantité de code importante. Il est souvent nécessaire de faire des mises à jour durant plusieurs années. Si l'on ne pense pas à centraliser les données du jeu, il arrive un moment où faire une mise à jour est un risque, car on oublie tous les endroits où une donnée est inscrite dans le code! Exemple : L'exemple est un jeu (fictif) en tour par tour du nom de "war", ce jeu est l'équivalent de milliers de lignes de code et de dizaines voire centaines de fichiers. Dans ce jeu, on attribue des caractéristiques aux joueurs qui se renouvellent à chaque tour (un classique) ! On a donc entre autre:
Attention: Une des colonnes de la table war_perso est nommé "force", force est un mot-clef réservé à mysql, c'est pourquoi il est impératif de l'entourer de ` .
Tout çà en gardant en tête que nous avons des dizaines ou centaines de scripts et des milliers de lignes de code. Le problème c'est que si à un moment donné par exemple un an plus tard on se rend compte qu'il faudrait plus de force, il faudra alors reprendre tous les scripts qui utilisent la donnée de force initiale et les mettre à jour, ce qui peut prendre beaucoup de temps! Il est surtout probable d'oublier un des fichiers et donc de générer des incohérences ! De même si vous vous rendez compte que vous avez fait une faute d'orthographe, ou que vous vouliez traduire votre jeu pour ouvrir le jeu à d'autre pays, ça prendra du temps ! La solution : séparer et centraliser les données Il y a plusieurs méthodes pour le faire ce qui importe c'est d'y penser et de le faire. Voici quelques approches : Stocker dans des fichiers à part Les données peuvent être enregistrées sous différents formats (php, xml, javascript, txt etc…). Attention toutefois le temps d'accès à une variable ne doit pas être trop long ! C'est pourquoi dans l'exemple qui suis le format php est retenu, car il est naturellement court ! Cela dit avec de nombreuses données, il peut être judicieux de les séparer en plusieurs paquets de façon à ne pas charger des données inutiles au script qui les utilise ! De plus il est imaginable de faire une console d'administration qui modifie ces fichiers et ainsi de permettre à des Mjs de pouvoir opérer des réglages sans avoir besoin de demander à un programmeur ! Voici donc notre exemple, avec des données centralisées :
Stocker toutes les données dans une table d'une base de données Une autre solution est de tout mettre dans une table, cela dit attention l'accès aux bases de données est assez long ! En revanche, c'est peut être plus simple à mettre en place. Il faut donc bien peser le pour et le contre Faire un peu des 2 précédents Il peut être judicieux de faire un mélange des 2 effectivement. L'idée c'est d'éviter d'avoir des fichiers énormes et donc d'utiliser des ressources inutilement. Pour ce faire on met dans la base de données les données occasionnelles et dans les fichiers les données très courantes. Il semble judicieux de rassembler le tout avec une fonction ou une classe pour éviter de salir le script de traitement. Il y a sûrement d'autre façon Oui là je vous ai montré quelques façons que j'ai utilisées maintenant il y a sûrement d'autres approches pour le faire. Conclusion Voilà le but de ce tutorial était surtout d'attirer l'attention sur le problème de redondance des données dans les scripts. J'espère que maintenant vous essayerez de mettre en place quelques choses afin d'éviter cette erreur récurrente ! NB: Le problème est identique dans les bases de données, il y a d'ailleurs un tutorial à ce sujet. orthographe — pascaltje 2007/12/11 16:48 Question : il faudrait modifier le nom du champ 'force', qui est un mot clé réservé de MySQL, non ? cf le tuto "bonnes pratiques SQL" Zamentur : En fait l'exemple fonctionne parce qu'il y a utilisation de `` , mais c'est vrai qu'on devrait peut etre changer çà. LexLxUs : Si tu tiens à conserver ce nom, je pense que dans ce cas, il faut au moins un avertissement — Adrien Giboire 2007/12/11 19:20 Zamentur : c'est fait. |