SQL + tableau a double entrée

Fermé
nEm3sis Messages postés 710 Date d'inscription lundi 20 août 2007 Statut Membre Dernière intervention 9 avril 2012 - 4 août 2008 à 20:24
 Utilisateur anonyme - 7 août 2008 à 14:09
Bonjour,
je suis actuellement en train de développer un jeu php/sql
et j'ai besoin de pouvoir stocker les status des joueurs entre eux
c'est pas très clair alors exemple :

j'ai un tableau de ce genre
id\id| 1 | 2 | 3 ... 2000
  1  | x | x | x ... x 
  2  | x | x | x ... x 
  3  | x | x | x ... x 
...
2000 | x | x | x ... x 

et je voudrais le stocker
j'ai pensé a SQL mais je ne sais pas sous quel forme l'y mettre

avez vous une solution pour moi ?
A voir également:

4 réponses

nEm3sis Messages postés 710 Date d'inscription lundi 20 août 2007 Statut Membre Dernière intervention 9 avril 2012 113
6 août 2008 à 23:30
personne ?
0
Utilisateur anonyme
6 août 2008 à 23:37
Salut,
ouep tu fais une table id contenant les id de tous les personnages, et un autre appelée par exemple combat où tu prends un champ joueur1 contenant une id, un champ joueur2 contenant l'autre id, et un autre resultat contenant le résultat.
0
nEm3sis Messages postés 710 Date d'inscription lundi 20 août 2007 Statut Membre Dernière intervention 9 avril 2012 113
7 août 2008 à 12:01
Merci pour ton aide
mais ce que tu propose ne fait il pas un peu énorme ? 4million de ligne avec 3 champs par ligne ça fait énorme je trouve non ?
entre temps j'ai pensé a autre chose
j'ai tout stocké dans un unique fichier (4 000 000 octets ça m'a l'air mieu que dans la base de donnée)
et j'accède a la donnée voulu a l'aide de :
fseek($handle, ($id1-1)*2000+$id2);
fread($handle, 1);


penses tu que c'est une bonne idée ?
0
sandul Messages postés 3927 Date d'inscription jeudi 22 mai 2008 Statut Membre Dernière intervention 8 octobre 2010 723
7 août 2008 à 12:40
Salut,

Il est vrai qu'une table à 4M lignes commence à être grosse... Mais avec 3 ID par ligne de type numérique (si le score est limité et tu peux utiliser NUMBER(2), par exemple, c'est encore mieux) n'est pas qqchose de monstrueux. Par la suite, tout dépend de ce que tu veux faire: si tu auras besoins de requêtes diverses et variées concernant les scores, un base de données et faite pour, tu auras du mal avec ton fichier. Pareil pour la maintenance (supposons que tu veux effacer un score... Un simple DELETE dans la base, à comparer à la restructuration du fichier...). Sans parler des ROLLBACKS te permettant de revenir en arrière si erreur (il sera difficile de simuler ceci avec un fichier) ou des acccès concurrents...

Mais encore une fois, tout dépend de ton contexte. Si pas de mise à jour des scores, avoir un fichier peut convenir, par exemple...

++
0
Utilisateur anonyme
7 août 2008 à 14:09
Salut nEm3sis, sandul a très bien argumenté je trouve. Il est vrai que ça fait un peu beaucoup, mais c'est tellement plus pratique. En plus des int de petites tailles ça pèse pas lourd. J'ai une bd avec 3000 docs contenant auteur,titre,description etc... ça pèse un peu mais sans plus. Et la vitesse d'exécution des requêtes est très rapide quand même. Pour les nombreux emprunts j'utilise des foreign keys : association porteuse de données.
0