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 !
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 !
![[Image: 468-60.jpg]](http://fullmetalgalaxy.com/images/banner/468-60.jpg)