Si tu veux jouer sur le faible coût des NULL ça serait pour la solution 2 si j'ai bien suivi, hein ?
Si j'ai bien suivi aussi (car j'avoue avoir un peu de mal ce "matin") tu veux stocker ces infos pour les types de bestioles nan ? Pas pour chaque bestiole appartenant à chaque joueur. Donc, tu peux pas tout simplement faire un gros JSON pour la persistance mais surtout le charger en RAM au démarrage du serveur ?
Ou même générer un fichier de code source ? car c'est le genre d'infos auxquelles on fait référence tout le temps et qui ne pèsent pas bien lourd en RAM.
Bon et si c'est bestiole par bestiole ben du coup vu que ton API est déjà fixée, tu peux switcher entre différentes solutions sans casse. Donc je prendrais la plus simple à implémenter, la 3 il me semble.
Un article intéressant qui décrit le modèle de données du CMS le plus rapide au monde, basé sur PostgreSQL avec, notamment, des genre de hash, mais pas que : http://zotonic.com/documentation/670/data-model-erd
(en fait les hash de données ne sont pas des hash postgresql, ils sont stockés dans un champ binaire (donc grosse sérialisation mais hyper rapide) et servent de référence, ensuite un cache avec de vraies colonnes est construit à partir de cette référence, et là on se rapproche plus de ta première solution mais c'est généré par du code, pas à la mano)
Et c'est d'ailleurs ce qui me semble le plus efficace à la longue : le dev se fait chier à faire un truc chiadé, mais ensuite le type qui pond les contenus fournit un simple JSON (ou un panneau d'admin facile à implémenter en pur JS) tandis que le code utilise des colonnes optimisées à mort.
Si j'ai bien suivi aussi (car j'avoue avoir un peu de mal ce "matin") tu veux stocker ces infos pour les types de bestioles nan ? Pas pour chaque bestiole appartenant à chaque joueur. Donc, tu peux pas tout simplement faire un gros JSON pour la persistance mais surtout le charger en RAM au démarrage du serveur ?
Ou même générer un fichier de code source ? car c'est le genre d'infos auxquelles on fait référence tout le temps et qui ne pèsent pas bien lourd en RAM.
Bon et si c'est bestiole par bestiole ben du coup vu que ton API est déjà fixée, tu peux switcher entre différentes solutions sans casse. Donc je prendrais la plus simple à implémenter, la 3 il me semble.
Un article intéressant qui décrit le modèle de données du CMS le plus rapide au monde, basé sur PostgreSQL avec, notamment, des genre de hash, mais pas que : http://zotonic.com/documentation/670/data-model-erd
(en fait les hash de données ne sont pas des hash postgresql, ils sont stockés dans un champ binaire (donc grosse sérialisation mais hyper rapide) et servent de référence, ensuite un cache avec de vraies colonnes est construit à partir de cette référence, et là on se rapproche plus de ta première solution mais c'est généré par du code, pas à la mano)
Et c'est d'ailleurs ce qui me semble le plus efficace à la longue : le dev se fait chier à faire un truc chiadé, mais ensuite le type qui pond les contenus fournit un simple JSON (ou un panneau d'admin facile à implémenter en pur JS) tandis que le code utilise des colonnes optimisées à mort.