Cout requete sql?
fidjy5
Messages postés
10
Statut
Membre
-
SebManfred Messages postés 484 Date d'inscription Statut Membre Dernière intervention -
SebManfred Messages postés 484 Date d'inscription Statut Membre Dernière intervention -
Bonjour,
je suis face à un choix et je ne sais pas comment faire. Je dois créér une base annexe afin de réaliser des stats. Cette base est enorme (757tables!!) et je voulais savoir si une requete serait moins couteuse en temps sur 1table contenan beaucoup de champs ou alors sur 1table plus petite mais en faisant des jointures..
Merci d'avance
je suis face à un choix et je ne sais pas comment faire. Je dois créér une base annexe afin de réaliser des stats. Cette base est enorme (757tables!!) et je voulais savoir si une requete serait moins couteuse en temps sur 1table contenan beaucoup de champs ou alors sur 1table plus petite mais en faisant des jointures..
Merci d'avance
Configuration: Windows 2003 Internet Explorer 6.0
A voir également:
- Cout requete sql?
- Logiciel sql - Télécharger - Bases de données
- Migration base access vers sql server ✓ - Forum Access
- Cout recharge telephone - Guide
- Quelle requête écrire pour demander au moteur de recherche de présenter de préférence les pages web traitant de tennis mais pas de tennis de table ✓ - Forum Android
- Unable to extract temporary files for microsoft sql server express 2022 - Forum SQL Server
1 réponse
ça dépend... (réponse à la c..., je sais, je sais)
ça dépend de la structure, de ce que tu veux y mettre
l'avantage de faire des jointures, c'est que tu vas diminuer le nombre d'enregistrement de ta table "de tête"
ce qui veut dire que si tu as une table unique, tu vas avoir un nombre d'enregistrement considérable et le temps pour la parcourir va être considérable lui aussi.
si tu as des tables en étage, elles seront moins remplies, mais il faudra du temps pour faire les liens d'une table vers l'autre...
il faut en fait trouver le bon équilibre entre les 2
si par exemple tu as une table A et une table B, avec une jointure entre les 2, il se peut très bien qu'à chaque élément de la table A correspondent plusieurs dizaines d'éléments de la table B
dans ce cas, le système par jointure est préférable car le temps de tarcours de ta table A sera beaucoup moins important que dans l'autre solution
si au contraire tu as une liaison 1-1 entre ta table A et ta table B, il vaut mieux tout rapatrier dans ta table A, car au final, le volume de données est le même, le temps d'exploration de la table A est le même et il te faut rajouter à ça le temps de jointure.
ce que tu peux faire, si tu veux optimiser les temps de réponse, c'est créer des index
ça dépend de la structure, de ce que tu veux y mettre
l'avantage de faire des jointures, c'est que tu vas diminuer le nombre d'enregistrement de ta table "de tête"
ce qui veut dire que si tu as une table unique, tu vas avoir un nombre d'enregistrement considérable et le temps pour la parcourir va être considérable lui aussi.
si tu as des tables en étage, elles seront moins remplies, mais il faudra du temps pour faire les liens d'une table vers l'autre...
il faut en fait trouver le bon équilibre entre les 2
si par exemple tu as une table A et une table B, avec une jointure entre les 2, il se peut très bien qu'à chaque élément de la table A correspondent plusieurs dizaines d'éléments de la table B
dans ce cas, le système par jointure est préférable car le temps de tarcours de ta table A sera beaucoup moins important que dans l'autre solution
si au contraire tu as une liaison 1-1 entre ta table A et ta table B, il vaut mieux tout rapatrier dans ta table A, car au final, le volume de données est le même, le temps d'exploration de la table A est le même et il te faut rajouter à ça le temps de jointure.
ce que tu peux faire, si tu veux optimiser les temps de réponse, c'est créer des index
