Discussion :

[crystaldope]

Bonjour,

Je suis en train de developper un jeu a l'aide de Java, avec une persistence sur serveur Mysql.

Mon objet java dispose de 38 champs a récupérer.
Ces champs son recupérés lors du login, et l'update se fait a la deconnexion du joueur. Donc par connexion d'un joueur, cela fait seulement 2 requetes.

Mon objectif est le temps de réponse minimal, et non l'espace disque.

Ma question est la suivante:

38 champs, ca me parait enorme pour un enregistrement.
Cela influe- t- il sur le temps de recherche dans l'index ?
Dois je remettre en question la conception ?

Serait ce plus performant de serialiser mon objet java pour le pousser en blob dans la base ?

Je n'ai pas vraiment le temps d'effectuer des tests poussés, j'aurais aimé consulter l'avis de ceux qui sont apssés par la.

Merci par avance.

[Tillo]

Bonjour,

Je suis pas un pro du Java donc je ne peux pas te renseigner en ce qui concerne le Blob.
Par contre, en ce qui concerne ta table le 38 champs ça me parait énorme.
Je pense que ça ne va pas être le top question rapidité d'exécution du code et rapidité de recherche dans l'index.
Il faudrait que tu vois si tu ne peux pas diviser ta table en plusieurs autres.

Mais ça n'engage que moi....

@+
Tabouet

[SQLpro]

D'abord dans une base de données il y a des colonnes et pas des champs. Les champs c'est dans les formulaires...

Ensuite 38 ne veut rien dire du tout. Si c'est 38 booléens, suivant les SGBDR, cela peut n'occuper que 5 octets. C'est à dire rien du tout. Tot dépend donc du type des colonnes en jeu.
Enfin un SGBDR client serveur travaille essentiellement en mémoire. Il n'enregistre heureusement pas à chaque mise à jour (INSERT, UPDATE, DELETE).

A +