[barrkel]

If you're doing OLAP, you probably want dimensions, measures and operators that operate on time aggregations and shifts. You want rollups and drill downs along multiple axes, with subtotals and probably pivots.

SQL isn't wholly adequate for this, it's hard work to get the SQL right and if there's joins involved it's not hard to accidentally fan out and start double counting.

If you ask me, you want an analytic model of the data that is designed around measures, dimensions, with an anointed time dimension, and a way of expressing higher level queries such that it automatically aggregates depending on which dimensions you leave out, and gives you options to sort, pivot, filter etc. dynamically.

This doesn't look like entities, really, but it is a model between you and the SQL.

From my scan - not detailed - reading of the article, Moose looks too low level and not a useful abstraction to sit in the same logical place that ORMs do in OLTP databases.

[timgdelisle]

Very much agree with you, at this point the abstraction is too low-level to be considered a proper ORM (or whatever the acronym should be for OLAP) and we're progressively working our way up to the right level. I love the idea of operating at the dimensions/measures level. Hoping we address this concern in the next couple of releases! Really appreciate the feedback

[paulbar]

I fully agree. This is why I created a SQL query engine for my own need few years ago, it is not open-sourced. It is called SquashQL (https://github.com/squashql/squashql). It provides a "simple" API (available in Typescript and Java for now) to perform "complex" and "dynamic" SQL queries such as pivot queries, standard queries with rollups or partial rollups with the ability to hide totals and subtotals, time-series and hierarchical comparison, bucketing, drilling across and more...