Création
d'entreprise
Posez votre question Signaler

SQL + tableau a double entrée

nEm3sis 703Messages postés 20 août 2007Date d'inscription 9 avril 2012Dernière intervention - Dernière réponse le 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 ?
Lire la suite 

SQL + tableau a double entrée »

5 réponses
Réponse
+0
moins plus
nEm3sis 703Messages postés 20 août 2007Date d'inscription 9 avril 2012Dernière intervention 6 août 2008 à 23:30
personne ?

 Ajouter un commentaire
Ajouter un commentaire
Réponse
+0
moins plus
Sky34gl3 361Messages postés 20 juin 2008Date d'inscription 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.

 Ajouter un commentaire
Ajouter un commentaire
Réponse
+0
moins plus
nEm3sis 703Messages postés 20 août 2007Date d'inscription 9 avril 2012Dernière intervention 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 ?

 Ajouter un commentaire
sandul- 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...

++
Ajouter un commentaire
Réponse
+0
moins plus
Sky34gl3 361Messages postés 20 juin 2008Date d'inscription 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.

 Ajouter un commentaire
Ajouter un commentaire
Posez votre question
Ce document intitulé « SQL + tableau a double entrée » issu de CommentCaMarche (www.commentcamarche.net) est mis à disposition sous les termes de la licence Creative Commons. Vous pouvez copier, modifier des copies de cette page, dans les conditions fixées par la licence, tant que cette note apparaît clairement.
Dossier à la une
Passage au tout numérique : quel coût pour les particuliers ?