De façon alternative il est aussi possible de stocker le tableau sérialisé dans un champs texte.
Finalement comme pour la chaine de caractère plus haut, l'intérêt étant que c'est plus simple à gérer.
Sinon un des problème à mon sens c'est qu'il va falloir créer un tas d'algorithme pour gérer ces maps, car on aura pas la puissance du langage SQL...
Concernant le système de cache ou le système par fichier (ce qui revient presque au même au final) un trucs m'embête vis à vis du nombre de fichier qu'il pourrait y avoir : 50 joueurs et on a 1000 fichiers... En fait je pense qu'une bdd serait plus performante.
Pour la solution 1 enregistrement par case, c'était idiot j'avais pas pris le temps de faire le calcul pour constater qu'effectivement il y aurait trop de champs. En fait une base de donnée gérant le relationnel objet aurait pus faire l'affaire grâce aux OID et en définissant la liste des cases comme table imbriqué...
NB: pour le cas du tableau (ou même de la liste de case) il est possible d'économiser de la place en définissant un terrain par défaut (herbe/eau). Ainsi on réduit certainement de 20% au minimum la taille des données si le type de terrain est correctement choisis.
Sinon on peux aussi imaginer un système hybride, par exemple si il s'agit de jouer des parties sur les cartes on peux décider de stocker en bdd seulement les maps qui sont utilisé par des parties en cours. Ainsi on s'affranchie d'un travail long et fastidieux.
Je me demande aussi si avec l'index sur l'id de la map le temps de recherche serait si important avec la solution d'une case par enregistrement. En fait ce qui me fait peur c'est plus la taille de tout çà.
Dans les estimations les plus haute on a en fait 100 000 000 enregistrements d'environ 10 octets (pour 2000 joueurs), soit une table d'1Go avec un index portant sur environ 40 000 éléments (puisqu'il y a 40 000 map)+ l'index des positions le tout formant la clé primaire.
En fait rien ne dit que les performances seraient naze, par contre c'est pas le genre de trucs qu'on peux avoir en mutualisé vu la taille de la table!
Ici je n'ai pas tenu compte des optimisations cités plus haut.
J'essaierais peut être si j'ai le temps un de ces 4
NB: la methode par fichier sera quand à elle tout aussi lourde si ce n'est pas plus.
Donc ce que je conseille c'est de faire des tests, et choisir en fonctions
Finalement comme pour la chaine de caractère plus haut, l'intérêt étant que c'est plus simple à gérer.
Sinon un des problème à mon sens c'est qu'il va falloir créer un tas d'algorithme pour gérer ces maps, car on aura pas la puissance du langage SQL...
Concernant le système de cache ou le système par fichier (ce qui revient presque au même au final) un trucs m'embête vis à vis du nombre de fichier qu'il pourrait y avoir : 50 joueurs et on a 1000 fichiers... En fait je pense qu'une bdd serait plus performante.
Pour la solution 1 enregistrement par case, c'était idiot j'avais pas pris le temps de faire le calcul pour constater qu'effectivement il y aurait trop de champs. En fait une base de donnée gérant le relationnel objet aurait pus faire l'affaire grâce aux OID et en définissant la liste des cases comme table imbriqué...
NB: pour le cas du tableau (ou même de la liste de case) il est possible d'économiser de la place en définissant un terrain par défaut (herbe/eau). Ainsi on réduit certainement de 20% au minimum la taille des données si le type de terrain est correctement choisis.
Sinon on peux aussi imaginer un système hybride, par exemple si il s'agit de jouer des parties sur les cartes on peux décider de stocker en bdd seulement les maps qui sont utilisé par des parties en cours. Ainsi on s'affranchie d'un travail long et fastidieux.
Je me demande aussi si avec l'index sur l'id de la map le temps de recherche serait si important avec la solution d'une case par enregistrement. En fait ce qui me fait peur c'est plus la taille de tout çà.
Dans les estimations les plus haute on a en fait 100 000 000 enregistrements d'environ 10 octets (pour 2000 joueurs), soit une table d'1Go avec un index portant sur environ 40 000 éléments (puisqu'il y a 40 000 map)+ l'index des positions le tout formant la clé primaire.
En fait rien ne dit que les performances seraient naze, par contre c'est pas le genre de trucs qu'on peux avoir en mutualisé vu la taille de la table!
Ici je n'ai pas tenu compte des optimisations cités plus haut.
J'essaierais peut être si j'ai le temps un de ces 4
NB: la methode par fichier sera quand à elle tout aussi lourde si ce n'est pas plus.
Donc ce que je conseille c'est de faire des tests, et choisir en fonctions