Feature request - Specify join relationship such as many to one, one to many, one to one, and many to many joins
See original GitHub issueDescription
Specify join relationship such as many to one, one to many, one to one, and many to many joins.
Here’s the docs for this in looker
What problem does this solve?
This lets the “explore” house lots of information. Empowering users to do aggregations but also dig into specific rows. With looker the relationship description ensures that upon aggregations the measure are summed, counted, etc correctly. Otherwise with we will have incorrect counting due to multiple one to many joins.
This functionality is a big part of looker’s secret sauce and one of the reasons why looker is so useful.
Example (using redshift)
generate example tables
CREATE TABLE sale AS
(select 1 as sale_id);
CREATE TABLE gift_card AS
(SELECT 1 AS gift_card_id, 1 as sale_id, 20 as cash_value
UNION ALL SELECT 2 AS gift_card_id, 1 as sale_id, 20 as cash_value);
CREATE TABLE cash AS
(SELECT 1 AS TRANSACTION_id, 1 as sale_id, 10 as cash_value
UNION ALL SELECT 2 AS TRANSACTION_id, 1 as sale_id, 10 as cash_value);
Files
v_cash.sql
select * from cash
v_gift_card.sql
select * from gift_card
v_sale.sql
select * from sale
v_sale.yml
version: 2
models:
- name: v_sale
meta:
joins:
- join: v_cash
sql_on: ${v_sale.sale_id} = ${v_cash.sale_id}
- join: v_gift_card
sql_on: ${v_sale.sale_id} = ${v_gift_card.sale_id}
columns:
- name: sale_id
meta:
dimension:
number
- name: v_cash
columns:
- name: transaction_id
meta:
dimension:
number
- name: sale_id
meta:
dimension:
number
- name: cash_value
meta:
metrics:
total_cash_value:
type: sum
- name: v_gift_card
columns:
- name: gift_card_id
meta:
dimension:
number
- name: sale_id
meta:
dimension:
number
- name: cash_value
meta:
metrics:
total_gift_cash_value:
type: sum
Here’s what the output looks like in lightdash The answer should be 20 and 40 not 40 and 80 (double counts due to join mechanism)
Closing thoughts
Maybe this is a design pattern / feature where lightdash and looker bifurcate? Maybe this is bad design pattern and we should handle this in the dbt joins via groups bys in the tables to be joined to. Would be curious to hear thoughts!
Issue Analytics
- State:
- Created a year ago
- Reactions:1
- Comments:5 (3 by maintainers)
Top GitHub Comments
ah yes, symmetric aggregates: Looker’s secret sauce.
We have an open issue for dealing with symmetric aggregates here: https://github.com/lightdash/lightdash/issues/961
Defining the join relationships will definitely help with this too! (if you know that you’re defining a many-to-many or many-to-one join, then we could warn you that your metrics could be wrong). And, agreed, it gives you even more power to your tables 💪
not stale!