Salut,
pour moi, ça ne doit aps être stocké en JSON (sinon, autant ne pas faire de BDD relationnelle): tu dois avoir 3 colonnes dans une table soit "player" (qui a directement les infos du compte), soit éventuellement "player_game_stats" dans laquelle se trouve toutes les stats de jeu du compte (histoire de l'isoler des infos du compte comme l'email/pseudo/etc).
De plus, sur mon archi de jeu habituelle, j'ai tendance à nommer les champs "calculés" sous la forme "cp_*". Cela me permettra, quand mysql 8 sera utilisé chez OVH pour le mutualisé (ou quand je basculerai dessus car je crois que mysql8 est déjà dispo chez eux), de remplacer ces colonnes "cp_*" par des "VIRTUAL COLUMNS", c'est à dire des colonnes calculées & stockées dans la DB
Donc, dans mon cas, je ferai:
TABLE player_game_stats:
- id_player INT UNSIGNED NOT NULL
- gamelevel INT UNSIGNED NOT NULL DEFAULT 1
- units_count_bonus INT UNSIGNED NOT NULL DEFAULT 0
- cp_actual_units_limit INT UNSIGNED DEFAULT 0
& soit un TRIGGER "AFTER UPDATE" sur player_game_stats qui met à jour le cp_*, soit une procédure stockée (c'est ma solution usuelle) compute_player_stats qui recalcule cette table (UPDATE player_game_stats SET cp_actual_units_limit = 20 * gamelevel + units_count_bonus). L'avantage de cette procédure est de permettre un recalcul de cp_actual_units_limit si je change les règles du jeu. Genre, si je passe de *20 à *30, quand je déploie, j'exécute cette procédure stockée pour tous les joueurs et tout le monde récupère la nouvelle règle du jeu.
On pourrait utiliser une vue également, c'est une alternative possible. Je le fais dans le cas où le compute est trop récurrent, ou quand la donnée change de manière temporelle (genre si le nb d'unités était augmenté de 1 chaque heure), car là, impossible de faire un "compute" proprement (on peut faire un EVENT SQL, pour un truc qui se passe chaque heure, ca va, mais si c'est chaque seconde comme les distances entre les astres dans variispace, alors ça n'a pas d'intérêt).
Dans le cas d'une vue, cela ferait:
TABLE player_game_stats:
- id_player INT UNSIGNED NOT NULL
- gamelevel INT UNSIGNED NOT NULL DEFAULT 1
- units_count_bonus INT UNSIGNED NOT NULL DEFAULT 0
VIEW computed_player_game_stats AS
SELECT id_player, 20 * gamelevel + units_count_bonus AS actual_units_limit
FROM player_game_stats
Je devrais d'ailleurs un peu plus systèmatiser cette approche... J'ai parfois tendance à oublier d'exécuter le "compute_player_stats" quand je touche au gamelevel ou au units_count_bonus. L'inconvénient, c'est que ce sera moins facile de migrer vers des VIRTUAL COLUMNS, puisque la VIEW n'a pas le même nom que la table... D'où le fait que je reste quand même sur la 1ere approche.
Je ne trouve pas d'option dans le sondage représentant cette approche "3 colonnes (2 data de base + data calculée)". Donc, je n'ai pas voté
pour moi, ça ne doit aps être stocké en JSON (sinon, autant ne pas faire de BDD relationnelle): tu dois avoir 3 colonnes dans une table soit "player" (qui a directement les infos du compte), soit éventuellement "player_game_stats" dans laquelle se trouve toutes les stats de jeu du compte (histoire de l'isoler des infos du compte comme l'email/pseudo/etc).
De plus, sur mon archi de jeu habituelle, j'ai tendance à nommer les champs "calculés" sous la forme "cp_*". Cela me permettra, quand mysql 8 sera utilisé chez OVH pour le mutualisé (ou quand je basculerai dessus car je crois que mysql8 est déjà dispo chez eux), de remplacer ces colonnes "cp_*" par des "VIRTUAL COLUMNS", c'est à dire des colonnes calculées & stockées dans la DB
Donc, dans mon cas, je ferai:
TABLE player_game_stats:
- id_player INT UNSIGNED NOT NULL
- gamelevel INT UNSIGNED NOT NULL DEFAULT 1
- units_count_bonus INT UNSIGNED NOT NULL DEFAULT 0
- cp_actual_units_limit INT UNSIGNED DEFAULT 0
& soit un TRIGGER "AFTER UPDATE" sur player_game_stats qui met à jour le cp_*, soit une procédure stockée (c'est ma solution usuelle) compute_player_stats qui recalcule cette table (UPDATE player_game_stats SET cp_actual_units_limit = 20 * gamelevel + units_count_bonus). L'avantage de cette procédure est de permettre un recalcul de cp_actual_units_limit si je change les règles du jeu. Genre, si je passe de *20 à *30, quand je déploie, j'exécute cette procédure stockée pour tous les joueurs et tout le monde récupère la nouvelle règle du jeu.
On pourrait utiliser une vue également, c'est une alternative possible. Je le fais dans le cas où le compute est trop récurrent, ou quand la donnée change de manière temporelle (genre si le nb d'unités était augmenté de 1 chaque heure), car là, impossible de faire un "compute" proprement (on peut faire un EVENT SQL, pour un truc qui se passe chaque heure, ca va, mais si c'est chaque seconde comme les distances entre les astres dans variispace, alors ça n'a pas d'intérêt).
Dans le cas d'une vue, cela ferait:
TABLE player_game_stats:
- id_player INT UNSIGNED NOT NULL
- gamelevel INT UNSIGNED NOT NULL DEFAULT 1
- units_count_bonus INT UNSIGNED NOT NULL DEFAULT 0
VIEW computed_player_game_stats AS
SELECT id_player, 20 * gamelevel + units_count_bonus AS actual_units_limit
FROM player_game_stats
Je devrais d'ailleurs un peu plus systèmatiser cette approche... J'ai parfois tendance à oublier d'exécuter le "compute_player_stats" quand je touche au gamelevel ou au units_count_bonus. L'inconvénient, c'est que ce sera moins facile de migrer vers des VIRTUAL COLUMNS, puisque la VIEW n'a pas le même nom que la table... D'où le fait que je reste quand même sur la 1ere approche.
Je ne trouve pas d'option dans le sondage représentant cette approche "3 colonnes (2 data de base + data calculée)". Donc, je n'ai pas voté