←back to thread

171 points voat | 2 comments | | HN request time: 0.414s | source
Show context
taeric ◴[] No.42159583[source]
I find the appeals to composition tough to agree with. For one, most queries begin as ad hoc questions. And can usually be tossed after. If they are needed for speed, it is the index structure that is more vital than the query structure. That and knowing what materialized views have been made with implications on propagation delays.

Curious to hear battle stories from other teams using this.

replies(1): >>42160902 #
1. FridgeSeal ◴[] No.42160902[source]
Depends who your users are and what the context is.

Having been in quite a few data teams, and supported businesses using dashboards, a very large chunk of the time, the requests do align with the composable feature: people want “the data from that dashboard but with x/y/z constraints too” or “<some well defined customer segment> who did a|b in the last time, and then send that to me each week, and then break it down by something-else”. Scenarios that all benefit massively from being able to compose queries more easily, especially as things like “well defined customer segment” get evolved. Even ad-hoc queries would benefit because you’d be able to throw them together faster.

There’s a number of tools that proclaim to solve this, but solving this at the language level strikes me as a far better solution.

replies(1): >>42161205 #
2. taeric ◴[] No.42161205[source]
I supported a team at a large company looking at engagement metrics for emails. Materialized views (edit: manually done) and daily aggregate jobs over indexed ranges was really the only viable solution. You could tell the new members because they would invariably think to go to base data and build up aggregates they wanted, and not look directly for the aggregates.

That is so say, you have to define the jobs that do the aggregations, as well. Knowing that you can't just add historical records and have them immediately on current reports.

I welcome the idea that a support team could use better tools. I suspect polyglot to win. Ad hoc is hard to do better than SQL. DDL is different, but largely difficult to beat SQL, still. And job description is a frontier of mistakes.