Discussion :

[reezeus]

Bonjour à tous

Mon environnement de travail actuel est c++ et MS Access.
J'ai une table contenant environ 20 000 enregistrements et une trentaine de colonnes.
J'effectue mes requêtes depuis c++.
La plupart de mes requêtes sont toujours les mêmes, à savoir SELECT Currency, Account, Name..... WHERE Client_ID = '....' etc...
Quelqu'un saurait-il me dire s'il vous plaît quelle solution est la plus rapide :
- Effectuer directement cette requête dans ma table principale
ou
- Créer cette requête dans MS Access, puis lancer une requête comme SELECT * FROM myQuery WHERE Client_ID = '....'Merci d'avance.

Reezeus

[bstevy]

Sans parler d'efficacité, tu contrôles plus ce que tu fais en utilisant tes noms de colonnes. Avec l'étoile, tu ne sais jamais précisément ce que tu ramènes, ni dans quel ordre, et donc si tu veux envoyer parser ton résultat, il vaut mieux que tu saches d'où tu viens.

Ensuite, d'un point de vue efficacité, si tu fais un

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

select * from (select champ1, champ2 from matable)

plutot qu'un simple

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

select champ1, champ2 from matable

ça ne change absolument rien.
Si ce n'est que tu vas perdre du temps à créer toutes tes vues inutilement.

Après, ça peut être intéressant à la limite si tu as des jointures, ça te permet d'avoir une seule table avec les champs qui t’intéressent, mais ça ne change toujours rien aux perfs.

[reezeus]

Le truc c'est que la table va grossir avec le temps, et certainement à un gros rythme. Pas seulement en termes de records, mais aussi en termes de fields qu'on rajoute au fur et à mesure des besoins.
Et donc je me demandais si ce n'est pas plus rapide de lancer une requête sur une query "pré-construite" (qui contient donc forcément beaucoup moins de champs que la table principale), que sur la table principale.
A noter que la table ne contient aucune clé/index car aucun champ n'est unique (C'est une table "fourre-tout").
Il est vrai qu'aujourd'hui la table est relativement petite et donc ça ne fait certainement aucune différence, mais j'aimerai bien optimiser mes requêtes dès maintenant pour ne pas avoir à revenir dessus dans un an ou deux .
Merci de ton aide.

[bstevy]

Ben, dans tous les cas, vous aurez des choses à modifier... soit vous modifiez vos requêtes, soit vous modifiez vos vues, mais si vous changer votre modèle au cours du temps, y'aura de toute façon les changements à reporter dans les requêtes... reste à savoir où pour vous la modification est la plus facile à faire.

Par exemple, si le code en C++ est livré en prod, mais que la partie Access reste une partie paramétrable, il vaut peut-être mieux effectivement figer le code et modifier la partie Access (et respectivement).

Mais en termes de perfs, ça ne change rien !

[Waldar]

Oui pas de différence en terme de performance entre vos deux requêtes.
J'ai une préférence pour le code BDD dans la BDD toutefois.

Par contre, vous avez tout intérêt à indexer votre table sur la colonne Client_ID (un index normal non unique fera l'affaire).
Voir aussi les tutoriels et cours de formation pour apprendre SQL.

[escartefigue]

Un select * devrait être proscrit car :

- il ramène toutes les colonnes de la table, et on a rarement besoin de tout, or le transport des données a un coût, particulièrement dans une boucle itérative, et surtout si la table est volumineuse (ce qui n'est pas le cas ici) et/ou que les enregistrements sont longs (longvarchar, beaucoup de colonnes...).

- il rend le traitement sensible aux évolutions de la base de données alors que souvent, l'ajout d'une colonne dans une table ne devrait pas impacter les traitements

- il rend les études d'impact plus complexes, on ne saiit pas directement quel traitement utilise quelle rubrique

[CinePhil]

Il y a plusieurs choses qui m’interpellent...

J'ai une table contenant environ 20 000 enregistrements et une trentaine de colonnes.
...
Le truc c'est que la table va grossir avec le temps, et certainement à un gros rythme.

20 000 lignes (et pas enregistrements ! ) dans une table Access, c'est déjà pas mal ! Si ça doit grossir de façon importante, il faudrait envisager sérieusement de passer sur un vrai SGBDR sinon ça va ramer.
Puisque vous êtes sur la technologie Microsoft, intéressez-vous à MS SQL Server. Il existe une version gratuite.

la table va grossir avec le temps, et certainement à un gros rythme. Pas seulement en termes de records, mais aussi en termes de fields qu'on rajoute au fur et à mesure des besoins.

Normalement, on conçoit une base de données en réalisant un modèle de données structuré. Une fois le modèle réalisé et implémenté, il est en principe très rare de devoir y retoucher et, surtout, les applications utilisent les données mais ne touchent pas au modèle de données.
J'ai l'impression que vous utilisez Access comme un tableur !

A noter que la table ne contient aucune clé/index car aucun champ n'est unique

L'indexation ne se fait pas seulement sur les colonnes (et pas champ ! ) où ne se trouvent que des valeurs uniques mais aussi sur des colonnes avec des valeurs non uniques et même sur des groupes de colonnes.
Et ne pas indexer correctement sa BDD, c'est avoir l'assurance de performances catastrophiques au fur et à mesure que le volume de données augmente, ce qui va être le cas et l'est déjà avec vos 20 000 lignes.

Il est vrai qu'aujourd'hui la table est relativement petite et donc ça ne fait certainement aucune différence, mais j'aimerai bien optimiser mes requêtes dès maintenant pour ne pas avoir à revenir dessus dans un an ou deux

Vous ne parlez que d'une seule table. N'y en a t-il qu'une dans la bade de données ? Cela confirmerait mon impression que vous utilisez Access comme un tableur, à feuille unique, qui plus est.
Ce que vous devez surtout faire, pour améliorer les choses avant que ce soit la catastrophe, c'est de passer par l'étape modélisation de la base de données. On peut vous y aider dans le forum ALM / Schéma.

[StringBuilder]

Vu comme c'est parti, encore quelqu'un qui va venir râler qu'Access est pourri dans quelques semaines :o

Forcément, avec une unique table poubelle sans index, même le meilleur SGBD sera à genoux avant le premier million de lignes...

[reezeus]

Merci pour vos réponses.

@escartefigue
Le select * dont je parlais serait effectué sur une access query déjà existante, contenant donc uniquement les fields dont j'ai besoin.

@CinePhil
- On a un SQL Server, utilisé pour stocker les données de toutes les applications qui partent en prod. Ici, il s'agit d'un programme sur lequel on ne sera que deux à bosser dessus, il ne part pas vraiment en "prod" au sens professionnel du terme. Et j'aimerais que les données restent stockées en local sur Access, notamment pour l'accès facile (en terme de vue) qu'il procure.
- Pour ce qui est du modèle structuré de données, il va changer dans les mois à venir. C'est d'ailleurs pour cela que l'application ne peut pas partir en prod aujourd'hui.
- Pour ce qui est de l'indexation, je ne suis pas un pro du SQL (je crois que ça vous l'aurez compris !), la gestion du serveur SQL est généralement confiée à l'équipe IT, ce sont eux qui travaillent à l'optimisation de celui-ci. Je me suis renseigné sur l'indexation, très utile en effet, je vais l'appliquer.
- Je ne parle que d'une seule table parce que les autres n'ont rien à voir avec ce sujet .