I think Malloy is meaningfully different from previous attempts (e.g., PRQL), and describe why in the post, namely the inclusion of a semantic layer as part of the language. Take a look at the post, and would love to hear if you agree or not.
That's an example with lots of model definitions inline. The idea is that you would define various components separately so they can be reused (and to your point, broken down and debugged separately). Malloy brings the modularization and reusability that is missing from SQL itself.
It is the first thing I try to teach CS graduates: DRY ( re-usability) is not applicable in the SQL world. Trying to re-use code, as proposed in Malloy generally results in poor performing queries. Malloy also seems needlessly complex compared to highly successful tools like DBT.
One other reason that DBT is successful is the low threshold to migrate your existing codebase. It is larger than Typescript Vs JavaScript, however, it can generalky be done in a week or two.
Comments
I think Malloy is meaningfully different from previous attempts (e.g., PRQL), and describe why in the post, namely the inclusion of a semantic layer as part of the language. Take a look at the post, and would love to hear if you agree or not.
How is this better than the SQL equivalent? How can I break down this query and run parts of it for debugging purposes?
query: sessionize is { group_by: flight_date is dep_time.day group_by: carrier aggregate: daily_flight_count is flight_count nest: per_plane_data is { top: 20 group_by: tail_num aggregate: plane_flight_count is flight_count nest: flight_legs is { order_by: 2 group_by: [ tail_num dep_minute is dep_time.minute origin_code dest_code is destination_code dep_delay arr_delay ] } } }
That's an example with lots of model definitions inline. The idea is that you would define various components separately so they can be reused (and to your point, broken down and debugged separately). Malloy brings the modularization and reusability that is missing from SQL itself.
It is the first thing I try to teach CS graduates: DRY ( re-usability) is not applicable in the SQL world. Trying to re-use code, as proposed in Malloy generally results in poor performing queries. Malloy also seems needlessly complex compared to highly successful tools like DBT.
One other reason that DBT is successful is the low threshold to migrate your existing codebase. It is larger than Typescript Vs JavaScript, however, it can generalky be done in a week or two.