[Débats] Créer sa base de données

[dark_vidor]

quel type est le mieux ... explique toi stp

[Loetheri]

Je ne m'y connais pas vraiment.
Je te conseille pour avoir un aperçu très peu explicite la documentation MySQL

Cela dit, certaines tables sont plus appropriées pour des donnes qui changent beaucoup tandis que d'autres sont plus appropriées pour les données fixes ;-)

[dark_vidor]

ça sera de l'innodb pour ma part ... :heuuu:

[Roworll]

D'après ce que je sais et les tests que j'ai effectué, InnoDb n'est pas très performant pour les tables très dynamiques (avec beaucoup de lectures/écritures). Certes, avec les transactions il permet de mieux conserver l'intégrité des données mais niveau rapidité, attention aux à la dégradation des performances.

Ensuite, pour les parties accès aux données, il y a quelques règles élémentaires que je donne ici succintement :

- Essayer le plus souvent d'extraire les données en fonction des index.
Extraire 10 enregistrement sur une table de 500 000 lignes sera plus rapide si un index est correctement positionné et utilisé

- Eviter les SELECT * FROM [table] et préférer les SELECT [champ1], [champ2], [champ3] FROM [table]. Le SELECT * va ramener tous les champs sans distinction, générant ainsi beaucoup de traffic et d'utilisation de la mémoire sur le moteur MySQL. Spécifier les champs à ramener limitera le flot d'information (inutile de ramener l'adresse mail d'un joueur pour vérifier juste son mot de passe par exemple)

- Utiliser la syntaxe EXPLAIN de MySQL pour vérifier les index utilisés et la qualité des requêtes.

[dark_vidor]

- Utiliser la syntaxe EXPLAIN de MySQL pour vérifier les index utilisés et la qualité des requêtes.

Mais encore ^^ :heuuu:

Hum Innodb est pas le plus performant c'est normal il garanti l'integrité des données ^^ peut pas tout avoir ^^

[Roworll]

InnoDB ne garanti l'intégrité des données que si le système est correctement programmé. Même si les transactions sont accessibles sous InnoDB, il faut encore les utiliser a bon escient.

Les transactions posent des verrous et sur des tables fortements dynamiques, on peut arriver rapidement à un empilement monstrueux qui, bien que "garantissant" la cohérence des données va plomber les performances.

Quand à la syntaxe EXPLAIN, c'est très simple.

Prends ta requête sous PhpMyadmin ou un produit équivalent et ajoute EXPLAIN devant puis execute ta requête.

Tu auras alors des informations sur la méthode utilisée (quel index sur quelle table, etc) par le moteur de BDD pour exécuter la commande.
c'est ce que l'on appelle le Plan de Requête.

Cela permet de voir si on peut s'attendre à des problèmes.

Par exemple, tu fais un EXPLAIN sur une requête ta base de test sur une table qui contient 100 lignes. Le temps de réponse est correct EXPLAIN te révèle que les données sont lues séquentiellement, sans utiliser d'index.
Lorsque cela se passera sur ta base de production qui contient 250 000 lignes, il faudra t'attendre à de sérieux problèmes de perfromance.

Il est alors clair que l'ajout d'un index serait le bienvenu.

[dark_vidor]

Affichage des enregistrements 0 - 9999 (10000 total, traitement: 0.1098 sec.)
requête SQL:
SELECT *
FROM `game_biens`
WHERE 1
LIMIT 0 , 10000

outch ...



Des idées pour l'amélioration ? :heuuu:
J'ai des index avec la clé primaire ... m'enfin la dans ma requete sont pas utilisée en meme temps sur cette table la ça sera tjrs un

Code :

SELECT * FROM game_biens WHERE id_users = x

[dark_vidor]

Affichage des enregistrements 0 - 4380 (4381 total, traitement: 0.6324 sec.)
requête SQL:
SELECT *
FROM `game_biens`
WHERE `id_users` =2129395
LIMIT 0 , 5000

en même tmps 5000 lignes c'est rien ... :heuuu:


Rajout d'un index sur la colone id_users

Affichage des enregistrements 0 - 4380 (4381 total, traitement: 0.0580 sec.)
requête SQL:
SELECT *
FROM `game_biens`
WHERE `id_users` =2129395
LIMIT 0 , 5000

existe il un logiciel pour que je puisse faire tester cette requete x fois et avoir le temps moyen d'acces ?

[joshua]

tu as mis tes clés ou dans ta table?

[dark_vidor]

PRIMARY KEY (`id_biens`,`id_users`,`id_units`,`id_source`),
KEY `id_users` (`id_users`)