11-08-2013, 01:09 PM
Salut,
sérialiser les données dans une BDD m'a toujours un peu fait pleurer... C'est un peu comme certains concepteurs que j'ai connu, qui étaient ravis d'avoir une base de données avec 2 tables: 1 qui contient absolument n'importe quel objet (sérialisé) et une qui contient les liens entre ces objets. Bon, ben à ce compte là, autant ne pas utiliser de SGDB et faire deux fichiers binaires sur son FTP.
La problématique production / consommation / stockage peut se développer comme un système d'équations mathématiques. Si tu sérialises, tu auras énormément de difficulté à envoyer ces équations au SGDB, puisqu'il faudra d'abord récupérer les données, puis les désérialiser, puis les traiter (souvent, on utilise alors non pas une solution exacte mais une approximation type Euler avec un intervalle de temps dT par exemple), puis les resérialiser, et enfin les remettre dans la BDD... C'est d'un lourd et d'un long !
J'hésiterai plutôt entre la solution souple, mais couteuse ou la solution rigide mais légère et simple. Ayant des mutualisés limités en terme de place pour la BDD, j'utilise plutôt la solution rigide légère. L'ajout d'une ressource change énormément le gameplay, et donc, on n'ajoute pas des ressources "à la volée", toutes les 30 secondes. Le fait que ce soit un peu chiant n'est pas vraiment un problème (si c'était impossible, ce serait différent).
Si t'as une place illimité, je dirai que le choix entre souple ou rigide dépendra de la fréquence d'ajout de ressources que tu comptes avoir. Si tu comptes laisser l'ajout de ressources possibles "juste au cas où", j'opterai pour la rigide simple. Si l'ajout de ressources est prévu et régulier, j'utiliserai la souple lourde. Dans aucun des deux cas je ne me tournerai vers les sérialisés. J'ajouterai d'ailleurs que niveau place, les données sérialisés sont très couteuses (il me semble), puisque ce sont des chaînes de caractères.
Ah, aussi, le système simple dépend de la densité de chaque ligne: si tu as 20 ressources différentes (donc, 20 colonnes si j'ai bien suivit), et que chaque unité n'a généralement qu'une ressource ou deux, alors 18 colonnes seront à "0", ce qui peut faire beaucoup de données inutiles. En ce cas, la solution souple mais "lourde" sera finalement plus légère.
sérialiser les données dans une BDD m'a toujours un peu fait pleurer... C'est un peu comme certains concepteurs que j'ai connu, qui étaient ravis d'avoir une base de données avec 2 tables: 1 qui contient absolument n'importe quel objet (sérialisé) et une qui contient les liens entre ces objets. Bon, ben à ce compte là, autant ne pas utiliser de SGDB et faire deux fichiers binaires sur son FTP.
La problématique production / consommation / stockage peut se développer comme un système d'équations mathématiques. Si tu sérialises, tu auras énormément de difficulté à envoyer ces équations au SGDB, puisqu'il faudra d'abord récupérer les données, puis les désérialiser, puis les traiter (souvent, on utilise alors non pas une solution exacte mais une approximation type Euler avec un intervalle de temps dT par exemple), puis les resérialiser, et enfin les remettre dans la BDD... C'est d'un lourd et d'un long !
J'hésiterai plutôt entre la solution souple, mais couteuse ou la solution rigide mais légère et simple. Ayant des mutualisés limités en terme de place pour la BDD, j'utilise plutôt la solution rigide légère. L'ajout d'une ressource change énormément le gameplay, et donc, on n'ajoute pas des ressources "à la volée", toutes les 30 secondes. Le fait que ce soit un peu chiant n'est pas vraiment un problème (si c'était impossible, ce serait différent).
Si t'as une place illimité, je dirai que le choix entre souple ou rigide dépendra de la fréquence d'ajout de ressources que tu comptes avoir. Si tu comptes laisser l'ajout de ressources possibles "juste au cas où", j'opterai pour la rigide simple. Si l'ajout de ressources est prévu et régulier, j'utiliserai la souple lourde. Dans aucun des deux cas je ne me tournerai vers les sérialisés. J'ajouterai d'ailleurs que niveau place, les données sérialisés sont très couteuses (il me semble), puisque ce sont des chaînes de caractères.
Ah, aussi, le système simple dépend de la densité de chaque ligne: si tu as 20 ressources différentes (donc, 20 colonnes si j'ai bien suivit), et que chaque unité n'a généralement qu'une ressource ou deux, alors 18 colonnes seront à "0", ce qui peut faire beaucoup de données inutiles. En ce cas, la solution souple mais "lourde" sera finalement plus légère.