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
Utilisateur anonyme - 7 août 2008 à 14:09
A voir également:
- SQL + tableau a double entrée
- Double ecran - Guide
- Whatsapp double sim - Guide
- Tableau word - Guide
- Tableau ascii - Guide
- Tableau croisé dynamique - Guide
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
6 août 2008 à 23:30
personne ?
Utilisateur anonyme
6 août 2008 à 23:37
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.
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.
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
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 :
penses tu que c'est une bonne idée ?
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 ?
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
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...
++
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...
++
Utilisateur anonyme
7 août 2008 à 14:09
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.