[SQL/SGBD] Enregistrement Long ou "Multi-Enregistrement"

[Kurogane]

Bonsoir,

Je n'arrive pas à trouver de réponse concrète à ce sujet :

Dans un SGBD ( Notamment dans mon cas Mysql ) ,
Vaut-il mieux stocker ces données dans un seul enregistrement "Long" , c'est à dire multitude de champs ou alors faire plusieurs enregistrements "Courts" ?

Je vais donner un exemple pour illustrer :

Supposons que j'ai une table intitulé "Bâtiment" ,que dans le jeu il existe 121 bâtiments.
Vaut-il mieux faire un enregistrement de type :
"Id_Lieu,Bat1,Bat2,...,Bat121" (Enregistrement Long )

ou alors :
"Id_Lieu,Bat_Type,Bat_Niveau" (Enregistrement Court)

Dans l'exemple le Lieu appartient à un seul joueur. Donc pour chaque joueur un Lieu et les bâtiments qui y sont construit.


Ici je ne parle pas dans soucis du code pour gérer cette table mais dans l'optique d'utiliser le moins de ressources possibles du coté SQL.


Bien-sur dans ce cas nous supposons que le jeu cité comporte des milliers de joueurs afin de voir les gains entre ces deux "Méthodes".


Cordialement Kurogane.

[Holy]

La question a déjà été posé à plusieurs reprises, la réponse est que ça dépend des cas ^^

J'imagine que dans la majorité des cas, tes joueurs n'auront pas 121 bâtiments remplis, et vu que tu as un nombre "illimité" de joueurs potentiels, il vaut mieux multiplier les lignes que les champs. Sans quoi si tu as mille joueurs, ça te fait 121000 champs même si ils sont tous vides, ce qui est quand même un peu ennuyeux.

De plus, pour la maintenance, c'est plus simple d'avoir une table courte, parce que ça veut dire que si tu ajoutes un bâtiment, tu ne dois pas modifier ta table.

[Argorate]

Faire autant de champ que de bâtiment en incrémentant le chiffre comme dans ton exemple est une très mauvaise façon de faire, tu perds tout l'interet d'une base de donnée et des relations entre les tables.

De plus avec une table bien faite, si un jours tu décide de rajouter un 122 bâtiments, tu ne seras pas obligé de touché a la structure de ta table!
De même si un jour tu veux retirer le bâtiment 83, tu fais quoi avec ta mega longue table?

Non, ce n'est pas viable, ni fait pour fonctionner de la sorte. Il te faut un enregistrement par bâtiment!

[php_addict]

jepense que tu as un autre soucis d'architecture de tes tables:

si ton jeu possède 121 types de bâtiments, il te faut une table genre data_batiments avec un id unique, nom, description, caractéristiques, etc......... cette table n'aura que 121 entrées

id (unique) , nom , description , prix, etc...
1 , mairie, la mairie c'est cool , 123000
2, saloon , le saloon on y boit , 500665
3, tour , sur la tour j'y monte , 4500

après tu te sert de l'id unique de tes bâtiments dans d'autres tables, par exemple dans une table batiments_constuits qui peut ressembler à ca:

id (autoincremente), id_du_batiment , id_du_joueur , date_de_construction , lieu_ou_il_est_construit , etc.......
1, 1, 12 , 3 juin 2010 , 87
2, 2, 56 , 2 aout 2010 , 65
3, 1, 89 , 1 juillet 2010 , 12
4, 3 , 32 , 12 septembre 2010 , 12

(exemple pourri, les dates doivent être des timestamp ou champ mysql adapté...)

[Kurogane]

Merci à vous, Désolé d'avoir reposé la question , je n'avais pas trouvé les précédentes --'

Pour le moment je fais avec des enregistrements courts et non ma table n'est pas ainsi c'était un exemple simplifié au maximum ^^

C'est le coté "Lourd" qui m'intéressait de ne pas faire, pour les modifications il est certes fâchant de devoir modifier une table et le code qui lui est lié.

Donc je resterais sur mes "Enregistrements Courts" comme je pensais.

[niahoo]

"""Sans quoi si tu as mille joueurs, ça te fait 121000 champs"""

non !

mais ils ont raison, ajouter un champ à chaque fois que tu vas créer un nouveau bâtiment c'est pas génial. Hmm par contre si pour d'autres données tu n'as que quelques champs (genre bois/pierre/food) c'est une bonne solution. mais pas 121