Commentaires sur : MySQL : Top 20 des meilleures pratiques !

Par : Johan Beneval

Johan Beneval — Mon, 10 May 2010 05:09:08 +0000

Bonjour Arnaud,

En écriture tes deux implémentations seront aussi performantes l’une que l’autre.

Par contre en lecture, théoriquement si tu as plusieurs milliers de légumes, la deuxième implémentation risque d’être moins performante que la première (de l’ordre de quelques ms), même si conceptuellement parlant c’est la meilleure des solutions !

Par : Arnaud

Arnaud — Wed, 05 May 2010 13:37:39 +0000

Très intéressant merci pour ces infos.
Une petite question de newbie. En terme de perf, vaut-il mieux avoir une grosse table (en terme de quantité de données) plutôt que plusieurs (presque) identiques, contenant moins de données ?

Pour illustrer : je veux gérer des choux et des carottes, les 2, héritant d’une classe Légumes. Soit je fais une table de choux et une table de carottes, sachant que les colonnes sont identiques (correspondants aux attributs des Légumes) sauf pour les carottes qui auraient un attribut spécifique « nombres par paquet ». Soit je fais 1 table « Légumes » en ajoutant une colonne « type » (de type enum, si j’ai bien suivi l’article) contenant les valeurs « choux, carottes » et dont la colonne « nombres par paquet » sera égale à 0 (et NOT NULL) pour les choux.
Y a-t-il une implémentation qui serait plus performante en écriture et/ou lecture (pour des requêtes seulement sur les carottes et des requêtes sur les 2 objets) ? ou est-ce uniquement un choix de design ?

Par : Adrien QUENTIN

Adrien QUENTIN — Wed, 16 Dec 2009 20:32:51 +0000

Great job!
pour ceux qui utilise des bases IBM DB2, le partitionnement horizontale et distribués(clustering) sont aussi tres puissant et viens avec de nombreuses fonctionnalités partiques pour archivage notemment.
Les notions d’index dans db2 permettent de gagner enormement en performance sur des grosses tables,l’indexation dans les fichiers de stockage meme de la db est aussi tres performant.
en terme de testing de performance,jmeter propose notemment un test de db avec connections concurrentes…
eviter aussi les triggers… il arrive que sur certaine manip de db, ceux ci se desactive tout seul et en plus ca coute en cpu cost…

tout ca existe surement sous oracle… a voir

tres bon article en tout cas ;)

Par : Paul LALOYEAU

Paul LALOYEAU — Mon, 07 Dec 2009 07:56:23 +0000

Merci, super intéressant!! :)

Par : Thibaut Lamanthe

Thibaut Lamanthe — Sun, 06 Dec 2009 18:13:18 +0000

Très intéressant !