Discussion :

[nlips]

Je viens de mettre en ligne AdaptiveLINQ (www.adaptivelinq.com).
Ce composant permet de construire des requêtes d'analyse (requête de la forme GroupBy) via une notion de cube et l'utilisation de la méthode .QueryByCube().
Cette méthode s'applique à toute collection de type IQueryable (ex : un jeu d'entités fourni par Entity Framework).
Cela permet de construire très facilement un "moteur d'analyse" (à l'image de ce que permet SQL Server Analysis Services et plus largement les technologies OLAP) requêtable via LINQ.
En combinant cela avec WCF Data Services, ce moteur devient requêtable via le protocole OData.
Essayez le et donnez moi votre avis !

[DotNetMatt]

Ca a l'air sympa Par contre, il y a quelques points qui me chiffonnent, et notamment l'analogie faite avec les cubes OLAP... N'hésite pas à me corriger si je suis à côté de la plaque.

Lorsqu'on crée un cube OLAP, pour le requêter, on utilise du MDX, qui permet de créer un jeu de tuples reflétant la structure dimensionnelle des données. Quel est donc l'intérêt d'utiliser du SQL relationnel "classique" ?

Autre point, d'après ce que j'ai pu comprendre en parcourant ton site, il faut se baser sur la base de données multidimensionnelle, et non sur le cube OLAP. On peut donc bénéficier de la modélisation dénormalisée de la base de données, mais pas des avantages offerts par le cube OLAP.

Autre point, quid des performances sur de gros volumes de données ? Quid des aggrégations complexes ? Quid des KPIs et autre calculs ? Par hasard, aurais-tu des benchmarks ?

En tout cas, ton produit a l'air complet (pas testé), mais je pense qu'il se destine plus à une niche. Non ?

[nlips]

Merci pour ce retour !
AdaptiveLINQ s'adresse à une application qui ne dispose pas d'une base de données OLAP.
C'est par exemple le cas d'une appli web qui utilise SQLServer Web Edition (cette édition ne dispose pas des fonctionnalités OLAP / MDX).
C'est certainement une niche.
En fait, avec AdaptiveLINQ, le cube est défini sous forme d'expressions .Net (C# pour le moment).
L'analogie avec OLAP se limite au "concept" (= dimensions et mesures) de cube.
Les expressions de dimensions et mesures sont utilisées (via la "compilation à la volée" qu'effectue AdaptiveLINQ) dans la requête LINQ qui s'effectue directement sur le modèle relationnel (la forme OLTP des données). C'est ce que j'essaye d'expliquer ici : www.adaptivelinq.com/Learn/HowDoesItWork.
L'opérateur .QueryByCube() va en fait se "compiler" en un .GroupBy(). L'idée est en gros d'apporter de la modularité à l'opérateur GroupBy.
Globalement, je dirai que l'on peut vouloir utiliser .QueryByCube() partout ou jusque là on utilise .GroupBy().
Les performances sont directement liées aux performances de l'opérateur GroupBy (AdaptiveLINQ ne manipule pas les données mais se contente de transformer une expression LINQ en une autre expression LINQ) et donc à l'implémentation du GroupBy par le fournisseur de données.
Par exemple, Entity Framework implemente un GroupBy LINQ en un "GROUP BY" SQL. Les performances sont donc liées à ce "GROUP BY" SQL. Et les performances de celui-ci dépendent beaucoup des index définis dans la base.
Je pense qu'il est temps que je construise un vrai projet d'exemple!