Discussion :

[Jinroh77]

Bonjour à tous,
Dans le cadre d'un projet, j'ai monté un petit entrepôt permettant de suivre des saisies de budgets sur des clients. J'ai
- moins de 100 000 clients
- 4 type de budgets (saisie en agence, opérationnel, encours, avancement)
- à peu près 200 000 lignes de faits avec plusieurs mesures (CA Interim, CA recrutement)

Je crée un cube assez simple là-dessus.

Maintenant la demande est de pouvoir identifier les Clients pour lesquels il n'y a aucune saisie en CA Interim ou CA recrutement.
L'idée est de créer un set dynamic répondant à la question avec quelque chose du genre

Code :

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

1
2
3
4
5
CREATE DYNAMIC SET CURRENTCUBE.[Client sans Saisie de Ca Recrutement ou Ca Interim]
 AS FILTER( [ClientProspect].[Client Prospect].[Client Prospect].Members, (
([Type Budget].[Type Budget].&[Saisie agence], [Measures].[CA Interim]) *
([Type Budget].[Type Budget].&[Saisie agence], [Measures].[CA Recrutement])
) = 0), DISPLAY_FOLDER = 'Filtres clients'  ;

Puis on me demande la liste des clients avec un EnCours en interim mais sans recrutement, puis un autre etc.

Le problème est que ces sets sont loin d'être rapide.
Pour si peu de données, sur une bonne machine, je me retrouve avec des temps terrifiant.
Moi qui voulait en plus proposer de l'écriture différée (WriteBack) ça devient complètent impossible (mais c'est encore un autre problème.


je me dis donc que les sets ne sont peut-être pas la meilleur solution pour répondre au besoin...

Qu'est ce que je peux proposer d'autres ?

je pensais conserver le cube pour aller regarder les chiffres tel que, en se baladant librement dans les données ; Puis créer à côté des rapports qui répondent aux différentes question.
Par contre les rapports ne se baseraient plus sur le cube, mais directement en SQL, avec des requêtes correctement indexées et plus rapide que ce que j'obtiens avec les SETS dynamiques.


Bref, qu'en pensez-vous ? Comment répondre au besoin ?

[Jinroh77]

Une petite aide sur le sujet ?

[anayathefirst]

Salut,

Je ne sais pas si ta question est toujours d'actualité, mais bon.

Je penses que tu y réponds en partie. La solution à mon avis serait de sortir du cube et de passer par autre chose (SQL par Exemple comme tu le suggère).

En effet, le cube n'est pas prévu pour des listing mais pour de l'analyse multidimensionnelle. Il faut réussir à convaincre le client que bien qu'il contienne toutes les données, le cube n'est pas optimisé pour ce type de requêtes .

Si le client n'a besoin que de listes, alors ta solution n'est pas dans le cube. Si par contre, ton client a besoin de connaître les encours en Interim pour les clients qui n'ont pas d'encours en Recrutement, ça risque de devenir compliquer : soit tu fais une requête spécifique en MDX pour cette demande, soit tu envisage des des dimension changeante avec des attribut "encousIntermi" et "encourRecrutement". Mais Je n'aime pas la deuxième solution car elle n'est vraiment pas optimal.

[Jinroh77]

Le sujet est toujours d'actualité , merci d'y répondre.

Effectivement, le cube n'est pas fait pour du listing mais la demande est à cheval ici, il s'agit de donner les valeurs associées à ceux qui ont tel encours à 0.
Mais effectivement, je me rends bien compte que le cube a beaucoup de mal à y répondre, car cela repose tout d'abord par un listing, puis une édition des valeurs.

L'idée est alors de sortir cela avec une requête spécifique, mais dans ce cas, je me retrouve à devoir prévoir et créer les x demandes spécifique que le client va pouvoir demander.

Le rapport simple que j'imaginais avec seulement un paramètre qui décrit le filtre et switch ensuite sur un set n'est plus vraiment d'actualité.

Je dois créer, pour chaque "état d'analyse" une requête spécifique en MDX, pour au moins conserver l'utilisation du cube.
Il faudra expliquer ensuite que pour lire ces données dans le cube, cela ne sera pas possible directement... A moins que Excel propose ce genre de filtre sur les données ??