Hi @IM_01,

You define the metric logic once (measures) and a set of dimensions. At query time, you can group by any subset of those dimensions (or none), so your "All" case (no group by), "group by 1 column", "group by 3 columns", etc., are all just different SQL queries over the same metric view.

Example patterns over the same metric view:

-- Grand total (like "All")
SELECT MEASURE(total_revenue) FROM uc_customer_demo_catalog.metric_demo.orders_metric_view;

-- Group by whatever dimensions the user selected
SELECT
  country,
  MEASURE(total_revenue)
FROM uc_customer_demo_catalog.metric_demo.orders_metric_view
GROUP BY country;

SELECT
  country,
  product,
  MEASURE(total_revenue)
FROM uc_customer_demo_catalog.metric_demo.orders_metric_view
GROUP BY country, product;

So for a UI where users can change filters and choose any combination of dimensions, metric views are the recommended approach. They keep your metric definitions centralized and let the UI/SQL decide the group-by dynamically.

You only need to pre-calculate and persist aggregates in tables when you have a small, fixed set of aggregates and you need very tight latency and are happy to manage extra tables.

Even then, Databricks also offers metric view materialization (pre-aggregated views behind the scenes) so you can keep the semantic layer clean and still get performance.

If this answer resolves your question, could you mark it as “Accept as Solution”? That helps other users quickly find the correct fix.