[Résolu] Structure des tables pour un Ogame-like

[QuentinC]

Là, il faut que tu comprenne que il faut accepter de perdre un peu de performance, et de produire un code acceptable. Parce que la première structure est vraiment mer**ique, et peut-être même pas plus rapide d'ailleurs. Tu dis 100000 lignes par table, et tu penses que c'est gros. Pour un SGBD c'est ridicule, par contre 70 colonnes, ça fait mal!

Ah, c'est bien pire à gérer 70 colonnes que 100000 lignes ? J'avoue mon ignorance sur ce point...

Là tu te trompes. Structure 1, tu ajoutes un bâtiment, faut rajouter une colonne, et changer toutes tes requêtes, car une bonne requête précise les noms de champs genre : SELECT champ1, champ2...

Donne-moi une bonne raison d'expliciter tous les champs plutôt qu'utiliser *. Je n'ai pas la possibilité de construire des objets partiels, et d'ailleurs quel est l'intérêt ?
Sachant que j'utilise un ORM maison ultra-simplifié et que pour récupérer une ligne, j'ai juste à faire Record::findFirst('Ville', array('id'=>7)); et hop j'ai un objet Ville avec toutes les propriétés remplies (vive PDO).

Alors que la 2, si tu offre un nouveau possible, eh ben tu rajoute RIEN! Tu donne seulement au joueur la possibilité d'acheter le nouveau bâtiment, auquel cas tu ajoute une ligne dans ta table bâtiment. Mais faut pas mettre de lignes avec nombre = 0!

C'est vrai, dans l'absolu tu as raison, je ne suis pas obligé de mettre des lignes avec nombre = 0. Bien vu.

Le mieux, c'est une table liste_batiment, il te suffit de rajouter un bâtiment à cette table, et il apparaît dans la liste des constructions automatiquement, etc... Faut pas faire un if($_POST['batiment'] == 1)... elseif...

J'ai de toute façon écarté la longue liste de if...elseif...else depuis longtemps. Je ne suis pas un imbécile quand même, je fais de la programmation depuis assez longtemps pour savoir que c'est un cauchemar.
J'aurais en fait utilisé des tableaux constants du genre :

Code :

$prixBatiments = array(
array(50, 50, 0, 0),
array(100, 150, 50, 0),
array(100, 0, 100, 50),
//...
);

Par contre j'ai du mal à voir l'avantage de stocker les coûts et ce genre de propriété permanente dans la base plutôt que définir des constantes php (on s'entend sur le terme de constantes, puisqu'un tableau ne peut techniquement pas être constant en php)
Là aussi j'aurais besoin d'un argument pour me démolir.

C'est plus une requete INSERT ...ON DUPLICATE KEY UPDATE pour moi.

Replace into tu veux dire, non ? Ou bien c'est pas pareil. Je sais pas, j'ai jamais utilisé insert ... on duplicate key update, mais j'ai l'impression que c'est la même chose.
Enfin, ça m'arrangerais bien.... je ne fais plus d'insert ni d'update depuis que j'ai découvert replace. Je ne sais pas si ça a des influences négatifs en fait.

Faux et horrible !
Tu enregistres uniquement le ratio pour un certain temps et tu le calcules lors de la modification.
Faut pas hésiter à rajouter 2/3 champs, uniquement pour limiter les calculs de ce genre.

J'ai du mal à te suivre.
A chaque mise à jour des ressources, il faut bien que je connaisse le nombre d'unités et le nombre de bâtiments de chaque type pour pouvoir calculer combien de ressources ont été produites et combien ont été consommées.
« Ajouter quelques champs » consisterait à cumuler les deux structures ? je comprends pas trop où tu veux en venir...

EDIT : suppression. Je m'apprêtais à dire une grosse bêtise