Je n'abonde clairement pas dans ton sens, Arkhanz, car la méthode du "je stocke une chaine sérialisant les données" (exemple: liste d'id d'unités "1,2,5,25,81,46,32") supprime tout l'intérêt d'un SQL (ou même d'un SGDB en général).
→ Il serait alors impossible de cherche une unité avec un id précis, ou avec des caractéristiques précises
→ Impossible de mettre à jour une unité sans charger, désérialiser, modifier, resérialiser et updater toute la liste des unités
→ Hermétique à l'évolution, puisqu'il faudra bousculer tout le schéma de sérialisation quand on voudra ajouter des nouveautés.
Si le jeu a 1.000 joueurs, chacun avec 10.000 unités, et bien une table de 10.000.000 de lignes (une par unité) est tout à fait adaptée. Le SGDB est là pour gérer ces cas (recherche de données dans des tables à nombreuses lignes), alors ne coupons pas son système (optimal en plus!) de recherche et de fonctionnement avec des bricolages
→ Il serait alors impossible de cherche une unité avec un id précis, ou avec des caractéristiques précises
→ Impossible de mettre à jour une unité sans charger, désérialiser, modifier, resérialiser et updater toute la liste des unités
→ Hermétique à l'évolution, puisqu'il faudra bousculer tout le schéma de sérialisation quand on voudra ajouter des nouveautés.
Si le jeu a 1.000 joueurs, chacun avec 10.000 unités, et bien une table de 10.000.000 de lignes (une par unité) est tout à fait adaptée. Le SGDB est là pour gérer ces cas (recherche de données dans des tables à nombreuses lignes), alors ne coupons pas son système (optimal en plus!) de recherche et de fonctionnement avec des bricolages