BDD ou fichiers ou classes ?

[Max72]

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 !

[Ter Rowan]

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

[Max72]

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).

[SorenS]

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.

[Xenos]

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:

// Modèles de données

interface IModel

{

}



//Modèle de données d'un batiment

interface IBatimentModel extends IModel

{

    public $id=0; // j'ai un doute sur cette ligne... l'id pourrait être stocké ailleurs que dans la classe du batiment-model à initialiser

}



// Classe mère de N bâtiments

abstract class AUsine implements IBatimentModel

{

    public $production = array(), $consommation = array(), $pointsVieMax = 0, $id = 0;

    // méthodes / attributs communs

}



// Modèle de puit de pétrole (données de base des puits de pétole)

class PuitPetroleModel extends AUsine

{

    public $id = 100; //Id du bâtiment

}



// Initialiseur des données du modèle

interface IDataFromSomewhere

{

    public function init($modelToInitialize);

}



// Initialiseur via SQL

class DataFromMySQL implements IDataFromSomewhere

{

    protected $mysql;

    public function __construct($mysql)

    {

        $this->mysql = $mysql;

    }

    public function init(IBatimentModel $modelToInitialize)

    {

        // Do the SQL query

        $data = $this->mysql->query('SELECT * FROM ... WHERE id='.(int)$modelToInitialize->id.' LIMIT 1');

        foreach ($data as $key=>$value)

            $modelToInitialize->$key = $value;

        //Doute là-aussi sur le ->$key... On peut se tapper setter/getter si on veut, mais c'est lourd à l'exec

    }

}



// Initialiseur via Classes

class DataFromClasses implements IDataFromSomewhere

{

    public function init(IBatimentModel $modelToInitialize)

    {

        $loadDataFrom = get_class($modelToInitialize);

        $className = $loadDataFrom . 'Data';

        $objectToLoadDataFrom = new $className();

        $objectToLoadDataFrom->loadTo($modelToInitialize);

    }

}



// Injecte des données dans un modèle

interface IDataModel

{

    public function loadTo(IModel $loadTo); 

}

class PuitPetroleModelData implements IDataModel

{

    protected $productions = array('petrole'=>6000, 'dechets'=>500);

    protected $consommations = array('energie'=>50000);

    protected $pointsVie = 5000;



    public function loadTo(IModel $loadTo)

    {

        $loadTo->consommation = $this->consommations;

        $loadTo->production = $this->productions;

        $loadTo->pointsVieMax = $this->pointsVie;

    }

}



$model = new PuitPetroleModel();

$dataFrom1 = new DataFromMySQL( new mysqli(...) );

$dataFrom2 = new DataFromClasses();

$dataFrom1->init( $model ); // le modèle sera initialisé par SQL

$dataFrom2->init( $model ); // le modèle sera initialisé par classe

// $model contient les données d'un puit de pétrole standard (peu importe l'origine de ces données)

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.

[Max72]

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

[Xenos]

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

[Max72]

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...#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 !

[Xenos]

Ah? C'est après le taf qu'on doit se reposer la tête? iffle:

[Max72]

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 :

<?php 

$house = new Ref_House(50);