Discussion :

[ouftinondidju]

Bonjour,

j'ai une requête avec des factures (IDFACTURE) par maison (IDMAISON) et la présence de personnes en mois. Je voudrais avoir (1) le total de la présence par facture et (2) le total par facture et par Etage. J'ai donc fait un Dsum, mais l'exécution de la requête est vraiment lente. Surtout qu'il y aura d'autres SomDom à faire par la suite et à regrouper (j'ai mis ici un exemple avec deux DSUM)

Initialement, je faisais des requêtes : 1 requête où je regroupe IDFACTURE et fais la somme de présence, une autre ou je fais de même en ajoutant les étages etc et puis je regroupe les requêtes, mais je me retrouvais avec pas mal de requêtes et ça devenait un peu laborieux de m'y retrouver. Du coup j'ai voulu regrouper mais l'option du SOMDOM ne semble pas optimale.

J'ai passé plusieurs heures sur le net pour trouver une autre solution et j'ai compris que les fonctions de domaines étaient à éviter. J'ai essayé de créer une fonction avec "Do While Loop" mais ça prenait également pas mal de temps pour générer le code et je maîtrise assez mal ces fonctions.

Je me tourne donc vers la communauté Je ne demande un code déjà tout prêt, mais peut-être juste une indication/direction et je ferai ensuite les recherches pour résoudre le problème, mais au moins savoir quelle piste plutôt explorer :
> est-ce que le meilleur moyen reste d'avoir plusieurs requêtes (une par calcul) ?
> est-ce que le SOMDOM est possible mais qu'il existerait une manière de rendre la requête plus rapide ?
> est-ce qu'il faut passer par du vba / créer une public function ?
> est-ce qu'il y a d'autres choses à essayer ?

j'ai vu que plusieurs personnes avaient eu le même problème et qu'on leur conseillait de maintenir plusieurs requêtes. Avant de me résigner à cela, je préfère m'assurer que j'ai tout essayé.


merci pour votre aide

[Belga16]

Si SOMDOM n'est pas optimale, ce n'est pas la faute de SOMDOM; il faut voir comment vous avez conçu votre BD et comment vous avez construit vos requêtes, car in fine ce que vous demandez semble fort simple à réaliser.
Si vous voulez, vous pouvez poster copie compressée de votre BD (avec info fictives), il y aura toujours qq'un pour concevoir une solution viable.

[Pierre Fauconnier]

Salut.

Pourquoi pas une requête avec regroupement. D'une façon générale, il faut éviter les fonctions de domaine, qui sont très chronophages et qui ont été créées pour faciliter le traitement pour des personnes qui ne maîtrisent pas SQL, mais ce ne sont que de pis-aller.

La conception de la BD n'a que peu à voir avec la lenteur du traitement. Ce qui crée la lenteur d'une fonction de domaine, c'est son fonctionnement.

Si SOMDOM n'est pas optimale, ce n'est pas la faute de SOMDOM[...]

Bien sûr que si que c'est la faute de SOMDOM. Il suffit d'en comprendre le fonctionnement pour se rendre compte qu'elle ralentira de plus en plus le fonctionnement de l'application au fur et à mesure de l'augmentation du nombre de lignes. C'est une fonction "confort" mais qui relance la requête à chaque invocation. je n'ose même pas imaginer cela en réseau... Merci donc de bien maîtriser les notions sur lesquelles vous vous proposez de répondre.

[ouftinondidju]

Bonjour,

merci beaucoup pour votre réponse rapide. Ca m'aide déjà beaucoup de savoir que le Dsum reste une piste.
J'ai ici repris ma base de données en isolant les tables nécessaires (en ne mettant que quelques données) et la requête avec mes deux Dsum et malgré tout, je vois que la requête peine à s'ouvrir.

Je précise que le Dsum se base sur PRESENCE qui est déjà un calcul généré via une Public Function. Donc je me suis déjà dit que l'accumulation de calcul pouvait être un souci. Ceci dit, j'avais essayé de scinder les requêtes : 1 requête avec les Présences que j'ai redéposées dans une table et une deuxième avec les DSUM sur base de la table et non plus de la requête, mais malgré tout, ça met du temps à s'ouvrir, voire plante le programme. Donc je pense que ça provient des Dsum.

Dans la version ci-jointe, l'ouverture de la requête est un peu lente, mais acceptable. Par contre dès qu'il y a des milliers de données, ça devient long.

merci bien


Database3.zip

[Pierre Fauconnier]

[...]ça met du temps à s'ouvrir, voire plante le programme. Donc je pense que ça provient des Dsum.

Dans la version ci-jointe, l'ouverture de la requête est un peu lente, mais acceptable. Par contre dès qu'il y a des milliers de données, ça devient long. [...]

Comme je l'ai dit, il est préférable de ne pas utiliser SOMDOM... Il faut bien comprendre son fonctionnement et on perçoit alors vite qu'elle inutilement lourde puisqu'elle crée une requête à chaque appel.

Il est de loin préférable d'utiliser une requête de regroupement. Une simple copie d'écran de la structure des tables, du formulaire en mode création ou utilisation et une bonne description du besoin devraient suffire pour apporter une réponse plus pertinente.

[...]Ca m'aide déjà beaucoup de savoir que le Dsum reste une piste.[...]

SOMDOM n'est clairement pas une piste. Il ne faut pas croire tout ce qui est donné dans les réponses, mais tester par soi-même et surtout COMPRENDRE comment travaille une fonction, surtout une fonction de domaine.

[ouftinondidju]

Bonjour

excusez moi j'ai répondu au message précédent avant d'avoir vu le vôtre.

Merci beaucoup pour votre réponse. Alors effectivement, ça rejoint ce que je lisais sur la lenteur des fonctions de domaine. Je vais me réorienter vers le regroupement.

Voici une photo, je pense que si j'ai bien compris, je procède au regroupement via IDFACTURE dans une requête et une deuxième requête de regroupement via IDFACTURE & ETAGE pour avoir le même résultat que les deux SomDom

[micniv]

Bonjour,
J'essaierais de faire une requete R1 chapeau qui calculerait PRESENCEMOIS du style :

Code SQL :

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

1
2
3
4
5
SELECT DétailFacture.N° AS IDFACTURE, Conventions.N° AS IDCONTRAT, Logements.Etage AS ETAGE, Conventions.Date_in, Conventions.Date_out, DétailFacture.[Date début], DétailFacture.[Date fin], ddd([DétailFacture]![Date début],[DétailFacture]![Date fin],[Conventions]![Date_in],[Conventions]![Date_out]) AS PRESENCEMOIS
FROM Occupants INNER JOIN ((Logements INNER JOIN Conventions ON Logements.N° = Conventions.logement.Value) INNER JOIN DétailFacture ON Logements.N° = DétailFacture.Logement.Value) ON Occupants.ID = Conventions.Occupants
GROUP BY DétailFacture.N°, Conventions.N°, Logements.Etage, Conventions.Date_in, Conventions.Date_out, DétailFacture.[Date début], DétailFacture.[Date fin]
HAVING (((DétailFacture.[Date début]) Is Not Null));
' voir à optimiser le GROUP¨BY

puis une requete R2 qui calcule ensuite [Presence/Etage] et [Presence/Etage/Fac] à partir de R1

mais sans doute que 2 requetes sans DSUM mais avec GROUP BY seraient plus rapides pour calculer [Presence/Etage] et [Presence/Etage/Fac]

[Pierre Fauconnier]

@Belga16

Si SOMDOM n'est pas optimale, ce n'est pas la faute de SOMDOM[...]

Bien sûr que si que c'est la faute de SOMDOM. Il suffit d'en comprendre le fonctionnement pour se rendre compte qu'elle ralentira de plus en plus le fonctionnement de l'application au fur et à mesure de l'augmentation du nombre de lignes. C'est une fonction "confort" mais qui relance la requête à chaque invocation. je n'ose même pas imaginer cela en réseau...

Merci donc de bien maîtriser les notions sur lesquelles vous vous proposez de répondre.

[ouftinondidju]

super merci pour vos réponses, ça me permet d'avancer !