BDD ou fichiers ou classes ? - 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 : BDD ou fichiers ou classes ? (/showthread.php?tid=7283) Pages :
1
2
|
BDD ou fichiers ou classes ? - Max72 - 07-01-2015 Hey ! J'ai encore une petite question pour le bon développement de mon jeu Comme je vous l'avais déjà expliqué, il s'agit d'un wargame en PHP, et il est possible de gérer plusieurs serveurs (chaque serv à sa BDD). Avec ceux-ci, j'ai une BDD de référence (que j'appelerai Ref) où je stocke tout ce qui est commun à chaque serveur (les bâtiments à construire, les utilisateurs (qui peuvent jouer sur plusieurs serveurs avec un seul compte user)). C'est sur cette dernière (Ref) que je me pose des questions sur sa réelle utilité : Tout le contenu de ma DB Ref est statique, hormis les comptes des utilisateurs. En effet, tous les bâtiments etc ne changeront que très peu (pour l'équilibrage ou nouveaux bâtiments, quêtes etc), donc je me demandais si, selon vous, l'emploi d'une DB est bien adapté : Le point positif à la DB est que les requêtes sont plus faciles (jointures toussa), bien que j'utilise un ORM assez simple, alors pour join 2 bases ça me demande un peu de boulot. Le point négatif est que (je pense) l'accès à la DB reste plus long que l'accès à un fichier dur, surtout avec plusieurs DB et tables. La raison me pousse à continuer dans ma lancée (sortir un proto le plus vite possible, hein Xenos ), mais en même temps si je décide un jour de virer les bâtiments de Ref pour les mettre en fichier, ça va me demander un boulot juste titanesque.. Sortir un prototype rapidement, c'est bien, mais si le code généré derrière est impossible à maintenir/faire évoluer, où est le gain ? HS : Je pense par exemple à Destinee Online qui, d'après ce que j'en sais, ont fait un très bon jeu, mais le code trop 'complexe' n'a jamais permit de faire évoluer le jeu.. On sait où ça en est Sinon, si les fichiers étaient choisis, pensez vous qu'il est plus agréable de travailler avec des fichiers simples (qui ne contiennent que des variables) qu'avec des classes ? Perso je pensais me tourner vers un système de : - Je créé plusieurs classes (mères), une par type de bâtiment (une pour les habitations, une pour les bâtiments de prod, de guerriers etc). Ces classes implémentent les méthodes de ce type de bâtiment, comme ça pas besoin de me les retaper dans chaque classe enfant, vu qu'elles font toutes le même taf. - Chaque bâtiment possède sa propre classe, classe fille du type de bâtiment. - Chaque classe (enfant) possède ses attributs, donc il est facile de savoir et gérer les gains, le prix etc de chaque bâtiment. Ou alors créer des fichiers simples, qui contiendraient des array avec les bâtiments, valeurs etc ? Je me répète, mais je n'ai pas envie de continuer dans ma lancée et m'apercevoir dans 6 mois/1 an que le système doit être revu, car c'est une très grosse partie du code qu'il faudrait réviser. Merci ! RE: BDD ou fichiers ou classes ? - Ter Rowan - 07-01-2015 si tu es sur du a peu près statiques, autant passer par un système de classe. L'intérêt de passer par la bdd serait plus important dans un monde plus "ouvert" (ou les joueurs peuvent inventer des bâtiments par exemple) autre raison potentielle de passer en bdd; si tu as énormément d'attributs pour un bâtiment Il est plus facile de faire une requête (voir une vue html sur la base) pour analyser les attributs d'un batiment que de se coltiner 200 lignes de code, même aussi simple que "$t->attr = 15" après si tu as quelques attributs, c'est l'inverse : il est facile d'ouvrir le fichier pour modifier les 5 valeurs enfin tout ça a mon sens RE: BDD ou fichiers ou classes ? - Max72 - 07-01-2015 Merci Ter Rowan. En effet, c'est même du très statique. D'où mon interrogation sur le stockage en DB (donc prévu pour du dynamique) des informations statiques. Sinon non, chaque bâtiment doit contenir entre 10 et 20 attributs (constantes en fait), et comme ces classes n'implémenteraient aucune méthode (contenues dans les classes parentes), je devrais me retrouver avec des classes qui ne contiennent qu'une 20aine de lignes. Par contre ça me ferait énormément de classes à gérer (peut-être 100 bâtiments différents, voire plus, pour 6 ou 7 types de bâtiments). RE: BDD ou fichiers ou classes ? - SorenS - 07-01-2015 Tu peux mettre en bdd je pense quand même. Tu rajoutes un cache sur ta requête sql pour améliorer la performance. Ça peux te permettre ensuite une administration plus facile par la suite. Tu en auras surement besoin, et c'est quand même plus simple soit direct en base soit via une petite admin. RE: BDD ou fichiers ou classes ? - Xenos - 07-01-2015 Perso, j'aurai placé un système d'interface (Mediator?) entre le code et le stockage des données (qui sera alors BDD ou classes). Donc, des classes représentent les bâtiments. Elles peuvent hériter de classes mères, ou être faites par composition. Elles contiennent les données du bâtiment, mais ces données ne sont pas initialisées dans la classe. Un autre objet, le Mediator, est alors chargé d'initialiser ces données. Cet objet peut alors être ou bien la classe "DataFromMySQL", qui ira piocher les données dans la BDD et les injectera dans l'instance de la classe du bâtiment ou bien la classe "DataFromClasses", qui chargera une classe (Model) contenant uniquement des attributs avec la valeur des données, ou bien même la classe "DataFromXML" qui lira un fichier XML contenant les données du bâtiment. Typiquement:
Code non testé Après, on peut avoir d'autres approches, comme se passer de "DataFrom*" et utiliser directement PuitPetroleModelData. On aurait alors un PuitPetroleModelDataFromSQL et PuitPetroleModelDataFromClasses, chacun avec une méthode init(IPuitPetroleModel) qui pren en entrée un objet représentant les puits de pétrole standard (normalement donc, un PuitPetroleModel). Là, le code est très extensible car on peut changer l'origine des données du puit de pétrole standard en ajoutant de nouvelles classes et en s'en servant pour initialiser ce puit de pétrole standard. On peut ajouter une classe pour charger depuis un XML ou un JSON par exemple... Ca, c'était pour la réalisation de code extensible. Pour l'origine des données, je partirai sur ce qui existe déjà (SQL si j'ai bien compris?) et j'insèrerai, plus tard quand ca sera utile, un objet chargeant les données depuis une classe, et les classes contenant les données des batiments. RE: BDD ou fichiers ou classes ? - Max72 - 07-01-2015 Waw, je ne m'attendais pas à une telle réponse, merci beaucoup Xenos. Je suis pas mal séduit par l'idée d'une interface, qui me permettrait d'avoir un code vraiment extensible. D'ailleurs, j'y avais déjà songé pour mon ORM : SI je souhaite un jour en changer, c'est tous les contrôleurs qu'il faut modifier :/ Pour le moment en effet, toutes mes références sont en DB et j'hésite à les passer en fichiers. Si j'hésite encore, c'est qu'il n'y a pas encore beaucoup de boulot à refaire, sinon j'aurai continué dans la voie de la DB. @SorenS : Oui, plus j'y pense et plus je me dis que la BDD offre bien d'autres avantages. Par exemple, si je n'ai que des fichiers, comment sélectionner plusieurs bâtiments qui produisent entre 200 et 400 PO par heure sans instancier chaque bâtiment ? Ou alors il faut des attributs statiques, mais charger tout de même tous les bâtiments (plus de 100 fichiers à include :/ ). Si je ne tranche pas sur le choix de la DB ou des fichiers, c'est que j'ignore si les références dans les classes ne me bloqueront pas à un moment (par exemple, facile de récupérer un bâtiment via son ID dans une DB, mais dans une classe ? Je ne veux pas instancier et parcourir tous mes bâtiments pour trouver celui qui a l'ID 50 :/ ). Je vais me lancer dans ta solution Xenos, et ainsi pouvoir gérer mes références en DB et par fichiers, bien que les exemples cités montrent vite les limites de l'utilisation des classes.. Merci à vous, vous m'avez épargné de tout coder avec juste des classes, ce qui je pense aurait dû être refait dans quelques jours/mois RE: BDD ou fichiers ou classes ? - Xenos - 07-01-2015 Pour tes exemples, même principe: construit une classe qui va répondre à la question "donne moi le modèle (objet PHP) de bâtiment dont l'ID est 50". Cette classe peut alors utiliser la BDD. Une autre classe (qui fait la même chose, aka répond à la même question) pourra utiliser les classes. Une autre, du XML. etc. Rien n'interdit d'ailleurs de mixer les deux: tu peux faire une BDD, et disposer d'une classe qui va re-générer les classes PHP à partir de la BDD (les DataModel de l'exemple). Ainsi, tu disposes d'une source de données "maître" (la BDD), mais tu as aussi les données sous d'autres formats (classes). Si l'appel à la classe chargée de passer les données de BDD en données de classe est lourdingue à faire à la main, crée une classe qui se charge de tester si cette conversion est utile et qui, si oui, l'effectue en appelant la première classe RE: BDD ou fichiers ou classes ? - Max72 - 07-01-2015 Oui c'est une autre idée en effet, qui m'avait déjà effleuré l'esprit lorsque je recherchais comment faire un système de quêtes : http://www.jeuweb.org/showthread.php?tid=10385&pid=123485#pid123485 Je vais analyser tout ce qui s'est dit ici, à tête reposée après le taf Je vous tiens au courant, en espérant pouvoir fournir un feedback intéressant Merci ! RE: BDD ou fichiers ou classes ? - Xenos - 07-01-2015 Ah? C'est après le taf qu'on doit se reposer la tête? iffle: RE: BDD ou fichiers ou classes ? - Max72 - 07-01-2015 Pour certains, oui ^^ J'ai essayé d'analyser les avantages qu’offrirait d'avoir les références en BDD ET en classes, et le seul que j'ai trouvé est de pouvoir diminuer le nombre de requêtes à la BDD. Passer tout sur la BDD est bien plus simple niveau code et rapidité de développement,surtout qu'avec l'ORM je n'ai qu'à faire un : Code PHP :
Je vais tout de même implémenter ton système (interface) Xenos, car je n'aime pas fermer la porte à un système qui me permettrait facilement, si le besoin s'en fait sentir, de diminuer le nombre de requêtes à ma DB. Si je reviens sur ma décision un jour, je tâcherai de vous en parler ici, peut-être que ça peut-être (beaucoup de suppositions avec ces peut-être ^^) intéressant. Merci à tous ! |