Tout sérializer avant de mettre dans la base de données

[Marc15]

Bonjour,

Dans le jeu que je suis en train de concevoir, le joueur dirigera une ville et devra gérer l'infrastructure, des bâtiments et des technologies.

Le fonctionnement des très simple.

Chaque infrastructure a un niveau. Donc le réseau routier pourrait avoir le niveau 7. Le joueur a besoin d'augmenter ce niveau quand la ville grandit, sinon ça créé des conséquences... bref, les détails sont pas importants ici.

Chaque bâtiment a un niveau maximal ainsi qu'un niveau fonctionnel. Ça veut dire que le joueur peut augmenter le niveau d'un bâtiment, mais seulement le faire travailler à moitié, par exemple si il manque de citoyens et qu'il veut concentrer ses efforts ailleurs. La mine d'or pourrait avoir un niveau 18, mais elle fonctionne seulement au niveau 9 (50 %).

Chaque technologie a un niveau. Tout simple.

J'ai donc rapidement fait une table pour les bâtiments, une pour l'infrastructure et une autre pour les technologies. Ensuite, je me suis dit que je pourrais tout mettre dans la même table.

Mais puisque ces informations concernent le joueur seulement et que je n'ai pas vraiment besoin de gérer ces unités individuellement, je pourrais tout simplement mettre les informations nécessaires dans un array et mettre tout ça dans un champs.

Quand je veux afficher la page de bâtiments, je vais chercher le string sérializé et j'affiche ce que je veux afficher. Même chose quand je fais un changement de tour. Je vais chercher les données, je fais les calculs, je resérialize et j'enregistre.

Ma question : Est-ce une bonne idée? Peut-être qu'il y a un truc que j'ai oublié. Est-ce que ce ça affectera les performances de façon positive vous croyez?

Merci

[Xenos]

Salut

Mauvaise idée. Plusieurs raisons:
- Si tu sérialize, il sera impossible, à postériori, de faire des recherches basées sur, par exemple, le niveau d'un batiment (je cherche les batiments de niveau supérieur à 9)
- Si tu sérialize, tout sera stocké sous forme de caractère ASCII ou UTF-8, soit 1 octet par caractère. Tu vas exploser la taille de la BDD (un tinyint, pour les niveaux des batiments de 0 à 255 par exemple, tient sur 1 octet alors que 255 prendra, en texte, 3 octets)
- Impossible d'utiliser des index propres, puisque les données ont été "collabées" (fusionnées) dans un champ texte; or, les index accélèrent les requêtes
- Tu vas rajouter 1 caractère d'échappement au moins pour séparer les données dans un champ, ce qui alourdis inutilement la BDD
- Si un jour tu veux rajouter des données, tu risqueras d'être coincé par la sérialization; en revanche, sans sérialiser, il est aisé de rajouter une colonne

Bref, mauvaise idée, tant du point de vue performances (pas d'indexes et des casts à tout bout de champ plus des sérializations/désérialisations) que du point de vue taille de la BDD (taille x3 si ce n'est pire) ou conception (pas possible d'ajouter des colonnes et très mauvaise habitude).

[Marc15]

Je crois que tu m'as convaincu.

Dommage c'était plutôt facile à utiliser et à implanter.

[php_addict]

fainéant (oups désolé c'est pas méchant)

économiser des tables en serializant c'est le pire que tu puisse faire en fait, tu peut pas faire pire...bosses sur la structure de tes tables, je pourrais te donner 1000 exemples que c'est vraiment la pire des solutions, mais pas le temps...en fait c'est même pas la pire des solutions, ce n'est pas du tout une solution

tu peut serialiser certains trucs mais pas des données aussi importantes, imagine le jour où tu change la structure de ton array() ! tu fais comment? bah t'es dans la merde...

courage !

[SorenS]

Imagine pour faire évoluer et maintenir ton jeu ensuite surtout ....

[Kroc]

Hum, c'est souvent une mauvaise idée en effet...

Mais ça se fait et tu n'es cependant pas en train de coder un appli pro, la sérialisation comporte beaucoup d'avantages :

- c'est facile à mettre en place, notamment pour stocker directement une arborescence de classe.
- la taille en base.. Je ne suis pas convaincu et il faut voir si c'est gênant.
- Les perf. peuvent être meilleur par rapport a faire une requête complexe.

L'important est d'être conscient des limitations: quelques petits pb pour faire évoluer le modèle (l'ajout/suppression de champs reste simple), pas de recherche sur ces données.
Franchement, vous voyez quoi d'autre ?

Et ce n'est pas être fainéant que de lancer un jeu par rapport à perdre ses soirées dans la conception d'un modèle de base.

[Sephi-Chan]

Dans ce cas, autant utiliser une base de données faîte pour ça. Par exemple MongoDB.

[php_addict]

Et ce n'est pas être fainéant que de lancer un jeu par rapport à perdre ses soirées dans la conception d'un modèle de base.

ok, fainéant n'est pas le bon mot, ok la serialisation sur le moment ca peut etre "Hourra, c'est rapide à mettre en place" puis quelques semaines plus tard c'est souvent "Aie aie aie comment je vais faire maintenant, tout refaire..."

perso seul les rapports d'actions sont serialisés, car sinon il y aurait au bas mots 40 champs dans la table rapports, et qui ne seraient pas tous utilisés suivant tel ou tel type de rapport, ou bien des 10aines de tables rapports, faut juste bien structurer les données serialisées car sinon c'est hyper chaud de changer la structure de données sérialisées

donc tant que faire ce peut il vaut mieux éviter...par contre si vous avez des exemples concrets comme quoi il est judicieux de serialiser alors ok je suis preneur par curiosité

[Kroc]

C'est marrant, je suis justement moins critique avec la sérialisation en base depuis que je l'utilise sur Google App Engine qui est proche de MongoDB.

Ceci dit, en quoi trouves-tu gênant cette sérialisation sur une base type SQL ? Et qu'apporte concrètement MongoDB sur cette utilisation ?

---

Des exemples concrets:

Mon jeu est structuré en partie qui n'intéresse qu'un nombre limité de joueur mais téléchargé intégralement à chaque fois. Chaque partie est répartie sur 3 tables (un seul enregistrement par table):
- des données en clair sur lesquels faire des requêtes. (game preview)
- un équivalent de blob contenant le gros des info (game data)
- quelques blobs (ok il peut y en avoir plusieurs par partie) pour l'archivage des actions.
Pour info, dans mon cas sur GAE, il n'est pas possible de charger une partie d'un enregistrement. (ie toujours select * ...)

La partie game data correspond à un modèle objet relativement complexe à sérialiser. J'utilise la sérialisation standard java (c'est le language que j'utilise), je n'ai donc aucun code à écrire et c'est robuste à quelques changements comme l'ajout de classe, de champs ou la suppression de champs.

Ce n'est pas toujours suffisant et m'impose de devoir écrire du code pour gérer la rétrocompatibilité. ex: je viens récemment de remplacer un champ désignant le joueur courant par une liste de joueur. (Si la liste est vide, je la reconstruis à partir du champ). Ce code étant supprimé quelques mois plus tard.

Lors d'un refactoring j'ai dû créer un script capable de désérialiser/resérialiser toutes mes données. Mais attention, les pb de migration de base existent aussi lorsque les données sont en clair.

Ce qui n'est pas pensable pour une appli pro qui devra lire des données créées il y a 15 ans, devient acceptable pour un jeu amateur. Ça tourne depuis plusieurs années (mais si il y a des joueurs ) et je ne compte pas tout refaire.

Je vous invite à expliquer clairement toutes les limitations auquelles vous pensez.

[edit] hum, c'est super cette façon de limiter les doubles post !

[Xenos]

SQL n'est tout simplement pas adapté à ce type de structure. C'est une BDD en arbre, pas un fatras de données textes