[MYSQL] Question structure table

9 réponses

Auteur	Message
radins \| Modérateur Inscrit le : 09/05/2005	# Le 14/10/2005 à 00:17 Je suis en train de réfléchir sur la structure optimale d'une table. Elle contiendra une centaine de lignes (donc presque rien) et il y aura des centaines de millies de requêtes par jour (donc plutôt pas mal beaucoup) dessus avec des ORDER et Where Vaut-ilmieux avoir trois colonnes un, deux et trois, "trois" contenant toujours la somme de un et deux donc un \| deux \| trois \| nom ---------------------- 2 \| 5 \| 7 \| truc 1 \| 3 \| 4 \| machin .... -> SELECT truc de table ORDER BY trois DESC .. ou éviter cette redondance en virant la colonne "trois" et la calucler à chaque requête, donc -> SELECT truc, un+deux de table ORDER BY 2 DESC ? Perso je préfère la redondance mais j'aimerais avoir l'avis de pros.. ;-)
PyRoFlo \| Florent Modérateur Inscrit le : 09/05/2005	# Le 14/10/2005 à 00:26 S'il n'y que quelques centaines d'enregistrements alors j'opterai pour la redondance (n'oublie pas d'indexer ce champ). Feu d'artifice Paris
Bool \| Olivier Modérateur Inscrit le : 09/05/2005	# Le 14/10/2005 à 00:41 J'opterais pour la redondance également, qui à priori te permettra d'utiliser un index. De plus, si le contenu n'est pas "crucial", une table HEAP serait très appropriée (stockage en mémoire, très très rapide). daevel : infogérance et conseil \|\| moi
devtribu \| Olivier Modérateur Inscrit le : 16/06/2005	# Le 14/10/2005 à 10:02 L'utilisation du type HEAP est recommandé en effet ! Si la table ne change pas souvent, que tu es en mysql 4.x, tu peux aussi utiliser le cache mysql qui fera merveille sur tous les select Février 2019, mon futur livre Tout JavaScript chez Dunod https://amzn.to/2PoLd0f
radins \| Tobias Modérateur Inscrit le : 09/05/2005	# Le 14/10/2005 à 11:40 Heap se perd au redémaragge du server, c'est bien ça? Dans ce cas je pense que ce sera une bonne idée de fiare une table HEAP pour l'utilisation et d'en faire une copie à chaque modif en "vraie" table, histoire d'avoir un sauvegarde (car les données contenues sont importantes quand même)? (Je précise que les modifs sont très rares..) (Message édité le 14-10-2005 à 11h46 par radins)
devtribu \| Olivier Modérateur Inscrit le : 16/06/2005	# Le 14/10/2005 à 11:58 Si tu as mysql 4.X, comme ta table ne bouge pas, utilises le cache mysql, les performances seront aussi bonnes qu'en heap sans les inconvenients de regenerer la table au reboot Février 2019, mon futur livre Tout JavaScript chez Dunod https://amzn.to/2PoLd0f
radins \| Tobias Modérateur Inscrit le : 09/05/2005	# Le 14/10/2005 à 12:22 Ok, merci, le souci est qu'il y aura aussi des ORDER BY RAND.. donc je penche pour heap.. Tiens devtribu encore un truc: dans ton (excellent) tuto sur http://www.toutjavascript.com/savoir/optimiser_mys... il y a une petite faute de frappe: "ANALYSE TABLE nom_table qui regénère les index de la table." ANALYZE marche mieux.. :-)
Bool \| Olivier Modérateur Inscrit le : 09/05/2005	# Le 14/10/2005 à 12:42 Surtout que le "ANALYZE TABLE" ne régénère rien du tout Ca permet à MySQL de mieux gèrer l'ordre d'utilisation des tables, des index, etc. dans une requete. daevel : infogérance et conseil \|\| moi
devtribu \| Olivier Modérateur Inscrit le : 16/06/2005	# Le 14/10/2005 à 12:46 Ok, je change ca bool > concretement ca fait quoi le analyze alors ? Février 2019, mon futur livre Tout JavaScript chez Dunod https://amzn.to/2PoLd0f
Bool \| Olivier Modérateur Inscrit le : 09/05/2005	# Le 14/10/2005 à 13:03 Il me semble que cela "analyse" les tables et leurs indexs, afin d'en sortir des données "statistiques" (nombre de lignes d'une table, nombre d'occurrences d'un index, etc). Et cela permet donc à l'optimiseur de se planter moins souvent. Et c'est une opération qui est généralement beaucoup plus rapide que la regénération des index. La doc de MySQL n'est pas très explicite à ce sujet, mais la plupart des SGBD ont une fonction équivalente... ils donneront peut être plus de détails (sous Informix c'est "UPDATE STATISTICS", et sous Oracle c'est également "ANALYZE TABLE"). daevel : infogérance et conseil \|\| moi

Auteur

Message

Inscrit le : 09/05/2005

# Le 14/10/2005 à 00:17

Je suis en train de réfléchir sur la structure optimale d'une table. Elle contiendra une centaine de lignes (donc presque rien) et il y aura des centaines de millies de requêtes par jour (donc plutôt pas mal beaucoup) dessus avec des ORDER et Where

Vaut-ilmieux avoir trois colonnes un, deux et trois, "trois" contenant toujours la somme de un et deux donc
un | deux | trois | nom
----------------------
2 | 5 | 7 | truc
1 | 3 | 4 | machin
....
-> SELECT truc de table ORDER BY trois DESC

.. ou éviter cette redondance en virant la colonne "trois" et la calucler à chaque requête, donc
-> SELECT truc, un+deux de table ORDER BY 2 DESC

?

Perso je préfère la redondance mais j'aimerais avoir l'avis de pros.. ;-)

PyRoFlo | Florent
Modérateur

Inscrit le : 09/05/2005

# Le 14/10/2005 à 00:26

S'il n'y que quelques centaines d'enregistrements alors j'opterai pour la redondance (n'oublie pas d'indexer ce champ).

Feu d'artifice Paris

Bool | Olivier
Modérateur

Inscrit le : 09/05/2005

# Le 14/10/2005 à 00:41

J'opterais pour la redondance également, qui à priori te permettra d'utiliser un index.

De plus, si le contenu n'est pas "crucial", une table HEAP serait très appropriée (stockage en mémoire, très très rapide).

daevel : infogérance et conseil || moi

devtribu | Olivier
Modérateur

Inscrit le : 16/06/2005

# Le 14/10/2005 à 10:02

L'utilisation du type HEAP est recommandé en effet !
Si la table ne change pas souvent, que tu es en mysql 4.x, tu peux aussi utiliser le cache mysql qui fera merveille sur tous les select

Février 2019, mon futur livre Tout JavaScript chez Dunod https://amzn.to/2PoLd0f

radins | Tobias
Modérateur

Inscrit le : 09/05/2005

# Le 14/10/2005 à 11:40

Heap se perd au redémaragge du server, c'est bien ça? Dans ce cas je pense que ce sera une bonne idée de fiare une table HEAP pour l'utilisation et d'en faire une copie à chaque modif en "vraie" table, histoire d'avoir un sauvegarde (car les données contenues sont importantes quand même)?

(Je précise que les modifs sont très rares..)

(Message édité le 14-10-2005 à 11h46 par radins)

devtribu | Olivier
Modérateur

Inscrit le : 16/06/2005

# Le 14/10/2005 à 11:58

Si tu as mysql 4.X, comme ta table ne bouge pas, utilises le cache mysql, les performances seront aussi bonnes qu'en heap sans les inconvenients de regenerer la table au reboot

Février 2019, mon futur livre Tout JavaScript chez Dunod https://amzn.to/2PoLd0f

radins | Tobias
Modérateur

Inscrit le : 09/05/2005

# Le 14/10/2005 à 12:22

Ok, merci, le souci est qu'il y aura aussi des ORDER BY RAND.. donc je penche pour heap..

Tiens devtribu encore un truc: dans ton (excellent) tuto sur http://www.toutjavascript.com/savoir/optimiser_mys... il y a une petite faute de frappe: "ANALYSE TABLE nom_table qui regénère les index de la table." ANALYZE marche mieux.. :-)

Bool | Olivier
Modérateur

Inscrit le : 09/05/2005

# Le 14/10/2005 à 12:42

Surtout que le "ANALYZE TABLE" ne régénère rien du tout

Ca permet à MySQL de mieux gèrer l'ordre d'utilisation des tables, des index, etc. dans une requete.

daevel : infogérance et conseil || moi

devtribu | Olivier
Modérateur

Inscrit le : 16/06/2005

# Le 14/10/2005 à 12:46

Ok, je change ca

bool > concretement ca fait quoi le analyze alors ?

Février 2019, mon futur livre Tout JavaScript chez Dunod https://amzn.to/2PoLd0f

Bool | Olivier
Modérateur

Inscrit le : 09/05/2005

# Le 14/10/2005 à 13:03

Il me semble que cela "analyse" les tables et leurs indexs, afin d'en sortir des données "statistiques" (nombre de lignes d'une table, nombre d'occurrences d'un index, etc). Et cela permet donc à l'optimiseur de se planter moins souvent.

Et c'est une opération qui est généralement beaucoup plus rapide que la regénération des index.

La doc de MySQL n'est pas très explicite à ce sujet, mais la plupart des SGBD ont une fonction équivalente... ils donneront peut être plus de détails (sous Informix c'est "UPDATE STATISTICS", et sous Oracle c'est également "ANALYZE TABLE").

daevel : infogérance et conseil || moi

Répondre

Vous ne pouvez pas participer au forum, car votre inscription n'a pas été validée. Pour vous faire valider en tant que Membre, cliquez ici.