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

[QuentinC]

Voilà donc pourquoi il est préférable de faire du 1, n : pouvoir faire des associations riches. Et quand bien même tu n'aurais besoin que d'associations simples, ta table de liaison ne contiendra qu'une paire d'id : pas de champs "custom".

Vous m'avez convaincu, Séphi en particulier, pour l'utilisation de ma seconde proposition plutôt que la première, donc l'association 1:n. JE vais écarter l'autre. Merci.
Si j'avais d'emblée eu des liaisons riches, je n'aurais même pas posé la question en fait, puisqu'on ne peut pas faire autrement dans ce cas-là. Ca aurait été évident. Mais je pensais que les inconvénients pour la solution 1 n'étaient pas si terribles que ça. Maintenant au moins c'est clair, ma première idée était pourrie.

Par contre Séphi, je ne suis pas tout à fait d'accord sur la suite, je cite :

Ainsi, chaque ligne dans cette table de relation représente une instance.

Dans ce cas ça signifie que si 1000 villageois habitent dans une ville, alors il y a 1000 lignes rigoureusement identiques dans la table de liaison. Étant donné que je n'ai pas d'informations additionnelles comme les pv, je ne vois pas ce que ça change avec un stockage unique villeId, type, nombre, donc avec un champ custom.
Autre point : un array de 1000 objets, c'est le bon truc pour faire exploser la RAM cette fois-ci. JE pense ne pas avoir besoin de manipuler chaque unité indépendament des autres, même en combat.
Ca pourrait certes être sympa de stocker les pv, mais après ça sera juste ingérable pour le joueur s'il a 1000 unités à disposition et s'il doit en choisir une bien spécifique parmi ces 1000 (je veux celle-là qui a presque plus de pv, pas l'autre). Je prévoyais plutôt qu'il puisse en sélectionner une de tel type, métaphoriquement « n'importe laquelle des unités de ce type ».
Imaginez une seconde le bordel si chaque vaisseau sur ogame avait des pv..... ce serait juste impossible de jouer sachant que certains ont des armées de 10000, 100000 vaisseaux.

Dans ce cas d'associations simples, un bon nommage de la table est players_pokemon_models : le nom de chaque tables (des pluriels) dans un ordre précis (alphabétique, en l'occurrence) concaténé par des underscores. Ce genre de convention est capital quand on utilise un ORM, car la classe associée prendra généralement le nom de la table mis au singulier (Player, PokemonModel).

Je suis allergique aux underscores, je préfère camelCase. Cela mis à part, c'est mon propre ORM ultra basique donc je programme ce que je veux. En l'occurence, je ne gère pas les liaisons de manière automatique (trop bourrin pour un avantage que je ne juge pas capital, encore une fois je ne suis pas convaincu par la chose mais ouvert aux discussions), et ma seule convention c'est une classe au singulier = une table au pluriel, + un fichier de définition contenant la structure de la table et des informations pour la validation automatique (là non plus je ne fais pas comme tout le monde, je n'ai pas opté pour du XML, trop malpratique à lire)

Et concernant le stockage des coûts en dur, c'est horrible. Si on suit le raisonnement, il y a beaucoup de choses qu'on peut stocker en dur dans des variables... Et pourtant, la base de données est faîte pour ça... Séparer les sources de données (ah ça c'est en DB, ça c'est en fichier, ça c'est donné par un web service, etc.), c'est mélanger les torchons et les serviettes : c'est mal et dangereux.

Tu peux développer ? Pourquoi est-ce mal ou dangereux ?
Mon argument contre est de dire qu'il s'agit de données constantes. Autrement dit une fois qu'elles ont été fixées, elles ne vont plus changer (sauf cas exceptionnel). Donc pourquoi sans cesse interroger la base de données sur des données constantes ? Je n'y vois là que des requêtes inutiles en plus, mais si tu me proposes cette possibilité, c'est qu'il y a sans doute un avantage que j'ignore encore.

Alors, pour le INSERT ON DUPLICATE KEY UPDATE, je m'explique. Imaginons le joueur n'a pas de ferme. Il en construit une, on rajoute une ligne pour la ferme. Il en construit une seconde, cette fois on modifier la ligne et on augmente le nombre de 1.
Ca se traduit pas le on duplicate key, c'est à dire on insère, et si la ligne existe déjà (même ville et même type de bâtiment) on update la ligne avec nombre=nombre+1.

Aha, pratique ! Mais alors ça fait presque la même chose que replace into. Je prends note, je ne connaissais pas. Merci.

L'avantage, c'est que dans ton interface d'admin tu peux rajouter un bâtiment facilement, et il apparaît tout de suite dans la page d'achat.

Pas faux ! Mais en même temps c'est pas censé arriver très souvent. Remarque ça peut être pratique pour des co-admin, si d'aventure ça arrivait...

Sinon, MyHotel, ton lien mène vers une page 404.

Si tu as le ratio, alors tu n'as jamais besoin de charger tous tes bâtiments à chaque modification. Te suffit juste de soustraire le ratio de l'ancien niveau et de rajouter celui du nouveau.

Je n'ai pas compris le ratio de quoi ? Désolé mais je ne te suis toujours pas.