Discussion :

[Pypiou]

Bonjour,

Quelqu'un s'est-il amusé a déterminer si une requête avec 2 ou 3 jointures
et 3 ou 4 fois 50 champs (3 ou 4 tables)
basée sur un MCD dont les noms de champs sont court

PR au lieu de PRENOM
DTN au lieu de DATE_DE_NAISSANCE
etc ...

rendait ses résultats plus rapidement sur un moteur SGBDR donné ?

Normalement oui, mais quel est le gain ?

A bientôt

[Waldar]

Le gain est / serait insignifiant.

La requête étant plus courte elle est transmise plus rapidement au serveur - ce qu'on peut éviter en utilisant des vues et/ou des procédures stockées - et la requête sera analysée plus vite par le SGBD.

Je ne pense pas que ce soit vraiment mesurable, surtout dès lors que vous avez des accès disques qui rentrent dans la danse.

[SQLpro]

Quasiment aucune incidence. C'est le genre de chose débile !
En effet, une requête est transmise dans un paquet qui fait en général 2 Ko.
Que tu y mette des noms court ou long, ce sera toujours 2 ko de chaine de caractères.....
Une fois dans le moteur, les noms sont changés en id donc longs ou courts ils occupent la même place !
Conclusion c'est du masochisme pur !

A +

[Pypiou]

...
Une fois dans le moteur, les noms sont changés en id ...

C'est de çà dont je voulais parler,

mais je n'ai pas été moi-même assez clair

Dans mon exemple ça donne 4*50 comparaisons de chaines (de disons 15 caractères, dans le cas de champs explicites) soit :
3000 comparaisons de caractères

contre

600 comparaisons de caractères dans le cas de champs abrégés

pour une requête.

Peut-être cela peut avoir une incidence mesurable, si on envoie une série de 10 requêtes de ce style, pour par exemple charger un plan de paye.

Mais c'est sur qu'entre les accès réseau(client->serveur) puis les accès disque(serveur) et a nouveau les accès réseau(serveur->client), le gain ne doit pas être transcendant.

Je me pose cette question parce qu'en fait j'ai travaillé chez un éditeur d'ERP, et J'ai bien vu la consommation en termes de volumes de bases de données
ou la lourdeur des traitements.

A+

[SQLpro]

C'est de çà dont je voulais parler,

mais je n'ai pas été moi-même assez clair

Dans mon exemple ça donne 4*50 comparaisons de chaines (de disons 15 caractères, dans le cas de champs explicites) soit :
3000 comparaisons de caractères

contre

600 comparaisons de caractères dans le cas de champs abrégés

pour une requête.

Peut-être cela peut avoir une incidence mesurable, si on envoie une série de 10 requêtes de ce style, pour par exemple charger un plan de paye.

Mais c'est sur qu'entre les accès réseau(client->serveur) puis les accès disque(serveur) et a nouveau les accès réseau(serveur->client), le gain ne doit pas être transcendant.

Je me pose cette question parce qu'en fait j'ai travaillé chez un éditeur d'ERP, et J'ai bien vu la consommation en termes de volumes de bases de données
ou la lourdeur des traitements.

A+

L'algorithme de Knuth Moris Pratt de comparaison de chaine de caractère vous donnera des vitesses bien supérieure et un nombre bien moindre de comparaison. L'écart final sera très faible.
De plus si la requêtes est déjà en cache et dans 98% des cas c'est probable, alors la traduction est instantanée, car la recherche est effectuées sur un hachage globale de la requête et non élément par élément.

A +