Discussion :

[ElMarlain]

Bonjour à tous!

Je travaille actuellement sur un jeu utilisant un coeur php objet et une interface flash. Mon problème est le stockage des très nombreuses variables en base de données. J'ai d'abord essayé de donner un champ pour chaque variable, mais je me retrouvais avec des tables absolument énormes et des requetes du meme type. Puis, j'ai découvert la fonction serialize(), qui transforme un objet en string, et permet de tout stocker dans un seul champ. La vie est d'un coup devenue plus facile.

Oui mais voilà, cette méthode pose un grave problème de sécurité au moment de l'envoi des variables à flash. J'ai donc entrepris de créer ma propre fonction de sérialisation, qui donnerait un string que flash pourrait comprendre, et qui règlerait mon souci de sécurité. Cependant, mes variables sont des objets qui contiennent eux meme des objets, qui peuvent parfois en contenir aussi... Cela rend les choses terriblement compliquées, et c'est encore pire quand on parle de déserialisation. J'ai pensé à la récursivité pour m'aider, mais j'ignore si php peut la prendre en charge, et de quelle manière. J'ai donc songé à revenir au "un champ : une variable".

Pourriez vous me conseiller là dessus? Est-ce trop gourmand en ressources que d'utiliser des tables contenant plusieurs dizaines, voir centaines de champs? Devrais-je me relancer dans ma sérialisation? Auriez vous un conseil ou deux pour m'aider dans cette tache?

Merci d'avance!

[sabotage]

Je pense que ce n'est pas tant le nombre de données mais la quantité qui entre en jeux.

[mon_nom_est_personne]

tu as bien fait de quitter l'idee de la serialisation car mettre de tel donne dans un db c'est pas top. demain tu upgrade ton jeu, tu t'aperçoit qu'une valeur dans la chaine serait mieu dans un champ dans une autre table, t'es bon pour tout faire a la main. Ou pire tu dois exraire de ta base cette meme donnée, tu va devoir extraire la chaine, la parser, sotir la valeur : pas top non ?
donc la structure classique de db pour ce genre de probleme et le suivant :

on va dire que tu veux mapper tes proprietes a un utilisateur, on va creer 4 tables :
- utilisateur : la ou tu mettra les info de l'utilisateur qui contient au moins un champ id
- propriete : tu va stocker ici les données qui precedement était dans ta serialisation mais de maniere unitaire. cette table contiens au moins 3 champs ; propriete id, propriete type id et propriete value.
- utilisateur propriete mapping : ici tu fait donc la relation entre ton utilisateur et ses n propriete. cette table contient au moins 2 champs ; utilisateur id et propriete id
- propriete master : ici tu decrit ce qu'est ta propriete . deux champs ; propriete id, propriete description.

donc pour recuperer les propriete d'un utilisateur, tu feras :
SELECT prop.propriete_value FROM propriete AS prop JOIN utilisateur_propriete_mapping AS map ON prop.propriete_id = map. propriete_id JOIN utlisateur as us ON us.utilisateur_id = map.utilisateur_id

apres t'en fait ce que tu veux.

[ElMarlain]

Mon souci est également l'optimisation... Etant donné la quantité importante de propriétés dans l'ensemble de mes objets, la méthode que tu me suggères ne risque-t-elle pas d'etre terriblement gourmande en ressources et en temps?