Impact de la modélisation sur les performances?

Impact de la modélisation sur les performances? - SQL/NoSQL - Programmation

Marsh Posté le 19-06-2003 à 21:29:39    

Bonjour à tous.
 
Voilà je me pose actuellement des questions sur les différences de performances (réelles) entre un MCD établit dans le respect strict des règles et un autre, qui n'y répond pas entierement.
 
Je m'explique:
- Dans une base de donnée (MySQL par exemple) est-il préférable, dans un souci de performance d'utiliser abondamment les données calculées dans les tables(nombres de messages d'un topic par exemple) que de passer par une requête qui recalculerait à chaque fois la donnée voulue(SELECT COUNT(*) ....)? Pourquoi?
- Est-il plus judicieux de mettre comme identifiant d'une table un numéro (int, long, ...) plutôt qu'une chaine de caractère? Par exemple, pour une table 'user', mieux vaut prendre comme identifiant le pseudo (chaine de caractere qu'on voudra unique) ou un numéro unique? Pourquoi?
 
Voilà, c'est quelques points que j'aimerai éclaircir mais dans un souci de performances uniquement (à partir de vos expériences personnelles si possible ;) )
 
Alors vous en pensez quoi?
 
Merci de données vos avis :jap:
 
PS: en fait g la structure de phpbb devant les yeux et je me dis qu'il y'a qd mm pas mal de données calculées  :sleep:

Reply

Marsh Posté le 19-06-2003 à 21:29:39   

Reply

Marsh Posté le 19-06-2003 à 21:41:32    

bah tout est question de compromis et de frequence de calcul
 
si pour un site tu dois faire une requete TRES lourde a chaque page alors que ca pourrait etre fait une fois et stocké... bah... si la taille que ca prend est pas trop eleve... vaut mieux le stocker...
 
C'est toujours comme ca, faire la balance entre la taille et la vitesse, en fonction de l'application
 
J'avais un prof lui c t "une base ca doit etre le plus petit possible"... c'est pas faut... mais alors le cauchemard a chaque traitement... :sarcastic:

Reply

Marsh Posté le 19-06-2003 à 21:48:37    

-VDV- a écrit :

que ca prend est pas trop eleve... vaut mieux le stocker...
 
C'est toujours comme ca, faire la balance entre la taille et la vitesse, en fonction de l'application
 


 
Justement g qd mm du mal à faire la balance comme tu dis. Vu que j'ai jamais travaillé sur des grosses BDD je peux pas vraiment voir ce que ça donne ;).
 
D'autres avis?

Reply

Marsh Posté le 19-06-2003 à 21:53:49    

Je pense qu'il faut faire la balance entre la quantité de requêtes de mise à jour, et la quantité de requêtes en consultation.
 
Si tu fais beaucoup d'updates mais peu de consultations (ou mettons que la balance soit équilibrée), alors les champs calculs sont plus indiqués.
 
Si tu fais peu d'updates mais beaucoup de consultation, évite les champs calculés.
 
Voilà, mon opinion qui n'engage que moi :)


---------------
Whichever format the fan may want to listen is fine with us – vinyl, wax cylinders, shellac, 8-track, iPod, cloud storage, cranial implants – just as long as it’s loud and rockin' (Billy Gibbons, ZZ Top)
Reply

Marsh Posté le 19-06-2003 à 22:05:19    

drasche a écrit :

Je pense qu'il faut faire la balance entre la quantité de requêtes de mise à jour, et la quantité de requêtes en consultation.
 
Si tu fais beaucoup d'updates mais peu de consultations (ou mettons que la balance soit équilibrée), alors les champs calculs sont plus indiqués.
 
Si tu fais peu d'updates mais beaucoup de consultation, évite les champs calculés.
 
Voilà, mon opinion qui n'engage que moi :)


 
en gros c ca
avec en plus le facteur "vitesse de calcul" et "poids de la requete" :p

Reply

Marsh Posté le 19-06-2003 à 22:13:38    

Grave question que celle là, c'est plus en rapport avec l'optimisation des process qu'avec le passage du MCD au MPD...
 
Bref, pour revenir à ton souci, il n'y a pas a priori de bonne méthode. Tu seras partagé entre ton COUNT(*) et le MAX(colonne).
Sache quand même que la solution basée sur le MAX(colonne) est à bannir, essentiellement à cause de la désorganisation potentielle de ta table: cela oblige le SGBD à lire toutes les lignes en séquentiel pour obtenir le résultat, alors que ton COUNT pourra s'appuyer sur les index de cette colonne.

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed