z3d a écrit :@Argorate > Ce que tu dis est absolument absurde; attention ne prends pas cela pour une attaque; voici pourquoi.

Utilisez une base de données et ce servir d'un champ dans lequel tu concatènes les pré-requis est un non sens, tu y perds la philosophie d'une base de données qui se veut être une structuration atomique de tes données. De plus, tu perds plus en pratiquant cette technique qu'en utilisant la base de données telle qu'elle doit l'être.

Une modélisation correct de ta base de données, te permet en une seule requête de récupérer des données structurées. Hors là, avec cette technique tu es obligé de traiter une nouvelle fois les données pour en retirer la quintescence. C'est une perte en temps et en ressources.

Donc plutôt que de faire de la concaténation, il faut une table qui contient autant d'entrée que nécessaire pour les prérequis d'une construction.

Voici un exemple :
Un bâtiment : Réservoir de Gazoil
Ses prérequis : Puit de pétrole niveau 1, Pipeline niveau 1

Supposons que le Réservoir de Gazoil possède l'identifiant 50, le Puit de pétrole possède l'identifiant 15 et le Pipeline possède l'identifiant 24.

La table des prérequis contiendra 2 entrées structurées comme ci-suit :
prerequis(id_construction, id_construction_requise, niveau_construction_requise);
prerequis(50, 15, 1);
prerequis(50, 24, 1);

Ainsi, il est plus aisé au travers de requête, sous-requête de savoir si il est possible de créer ce dit bâtiment.

Argorate a écrit :Ton exemple est super pour perdre de la place^^
Personnellement, je pense que si tu prévois un arbre Tech avant sur papier, tu as plus à changer quoi que se soit après, et pour les rare fois ou tu changes tu remets toute la séquence, ça ne pose pas grand soucis.
Pour traiter les données ce n'est pas l'idéal c'est sur, mais c'est très économe quand on prévoit un grand arbre technologique. Car remplir ta bdd de centaines d'entrées pour ça, je trouve que tu perds de la place pour rien, sans compter que tu perds également du temps en traitement les données dernières, pour trouver la bonne entré parmi toutes, et même pire, tu dois trouver tous les tuples concernant l'ID du bâtiment que tu test, alors qu'avec l'autre méthode, un tuples, un champ, terminer.
(C'est bien beau d'avoir plein d'infos en BDD, mais le serveur a ces limites, plus on perd du temps a faire plein de requêtes et a transférer plein de données provenant du serveur, plus on a de risque qu'un jour le serveur plante [ou meme des ralantissement, ça énerve -a juste titre- tres vite les joueurs], car il n'arrive plus a suivre ; C'est dans cette optique là que je propose cette alternative en tout cas.).

Bref, il faut voir le jeu en question, s'il n'y a pas beaucoup de bâtiment ni de relation entre eux c'est préférable de faire une table rien que pour cela, mais si il y en a trop, je ne suis pas sur que se soit le plus optimisé des systèmes (bien qu'il marche très bien).

IGstaff a écrit :manip -> il te faut le vérifier aussi quand le joueur a cliqué sur ton formulaire ou lien.
De plus, on utilises généralement ">=" au lieu de ">" car cela correspond au premier niveau atteint par le batiment A où le batiment B est visible/"achetable".
Enfin, on utilise généralement des boucles et des tableaux pour gérer cela(même en POO à mon avis...), je sais pas si tu le fais car ton exemple est général mais je le dis au cas où.

IGstaff a écrit :Satevis -> je conseille l'utilisation de la méthode JSON plutot qu'un fichier XML car c'est encore plus pratique et il parait que c'est plus rapide que le XML.