Utilizzo
join: view_name_2 {
sql_on: ${view_name_1.id} = ${view_name_2.id} ;;
}
}
Gerarchia
sql_on |
Valore predefinito
NessunaAccetta
Una clausola SQL ON Regole speciali
sql_on , sql_foreign_key e foreign_key non possono essere utilizzate contemporaneamente nello stesso join
|
Definizione
sql_on
stabilisce una relazione di join tra una vista e la relativa esplorazione, in base a una clausola SQL ON
da te fornita.
Per LookML, l'ordine delle condizioni in sql_on
non è importante. Quindi sql_on: ${order.user_id} = ${user.id} ;;
e sql_on: ${user.id} = ${order.user_id} ;;
sono equivalenti. Puoi inserire le condizioni in entrambi gli ordini, a meno che l'ordine non sia pertinente al dialetto SQL del tuo database.
Una visualizzazione può essere aggiunta direttamente a un'esplorazione quando viene utilizzato sql_on
oppure può essere collegata a una seconda visualizzazione già collegata a quell'esplorazione.
Un esempio del primo caso in cui una visualizzazione viene aggiunta direttamente all'esplorazione ha il seguente aspetto:
explore: order {
join: customer {
sql_on: ${order.customer_id} = ${customer.id} ;;
}
}
L'SQL generato da Looker a partire da questo LookML è il seguente:
SELECT ...
FROM order
LEFT JOIN customer
ON order.customer_id = customer.id
Nel secondo caso, una vista viene collegata a un Explore attraverso una vista intermedia già associata a quell'esplorazione. Esempio:
explore: order_items {
join: order {
sql_on: ${order_items.order_id} = ${order.id} ;;
}
join: customer {
sql_on: ${order.customer_id} = ${customer.id} ;;
}
}
Qui customer
non può essere aggiunto direttamente a order_items
. Deve partecipare invece tramite order
. L'SQL generato da Looker a partire da questo LookML è il seguente:
SELECT ...
FROM order_items
LEFT JOIN order
ON order_items.order_id = order.id
LEFT JOIN customer
ON order.customer_id = customer.id
Per fare in modo che funzioni correttamente, puoi vedere che utilizziamo semplicemente i nomi delle viste corretti nei riferimenti dei campi. Poiché customer
deve unirsi a un campo in order
, fai riferimento a ${order.customer_id}
.
In alcuni modelli meno recenti, potresti vedere campi a cui viene fatto riferimento con la sintassi
view_name.native_column_name
. Anche se questa operazione funziona, l'utilizzo della sintassi${view_name.looker_dimension_name}
presenta un vantaggio importante: puoi evitare di utilizzare il parametrorequired_joins
. Questo concetto è spiegato in modo più dettagliato nella sezione Utilizzarerequired_joins
quando non è possibile utilizzare la sintassi${view_name.looker_dimension_name}
in questa pagina.
Join condizionali
È anche possibile consentire l'utilizzo dell'input utente in sql_on
. Sebbene vi siano diversi motivi per farlo, l'ottimizzazione della velocità di query sui database MPP (come Redshift) è un caso d'uso importante, come descritto in questo argomento della community.
Per aggiungere l'input dell'utente alla condizione di unione, devi prima creare un filtro per il suo input. Questi tipi di filtri sono descritti più in dettaglio nella pagina Filtri basati su modelli. Ecco il modulo di base:
view: view_name {
filter: filter_name {
type: number | datetime | date | string
}
}
Dopo aver aggiunto un filtro per raccogliere l'input utente, puoi utilizzarlo nel parametro sql_on
in questo modo:
{% condition view_name.filter_name %} view_name.dimension_name {% endcondition %}
Ad esempio:
explore: order {
join: customer {
sql_on:
${order.customer_id} = ${customer.id} AND
{% condition customer.creation_date_filter %} customer.created_at {% endcondition %} ;;
}
}
Questo verrebbe interpretato nel significato di: imposta customer.created_at
uguale al valore di customer.creation_date_filter
.
Utilizzo delle variabili _in_query
, _is_selected
e _is_filtered
Liquid
Le variabili Liquid _in_query
, _is_selected
e _is_filtered
possono essere utili se utilizzate con il parametro sql_on
. Possono consentirti di modificare le relazioni di unione in base ai campi selezionati da un utente per la sua query. Ad esempio:
explore: dates {
join: dynamic_order_counts {
sql_on:
${dynamic_order_counts.period} =
{% dynamic if dates.reporting_date._in_query %}
${dates.date_string}
{% elsif dates.reporting_week._in_query %}
${dates.week_string}
{% dynamic else %}
${dates.month_string}
{% dynamic endif %} ;;
}
}
Esempi
Unisci la vista denominata customer
all'esplorazione denominata order
abbinando la dimensione customer_id
di order
con la dimensione id
di customer
:
explore: order {
join: customer {
sql_on: ${order.customer_id} = ${customer.id} ;;
}
}
Partecipa alla vista denominata customer
per esplorare il nome order_items
attraverso la vista chiamata order
. Abbina la dimensione customer_id
da order
con la dimensione id
da customer
. Abbina la dimensione order_id
da order_items
con la dimensione id
da order
. Questo valore viene specificato come segue:
explore: order_items {
join: order {
sql_on: ${order_items.order_id} = ${order.id} ;;
}
join: customer {
sql_on: ${order.customer_id} = ${customer.id} ;;
}
}
Unisci le viste denominate order
e inventory_items
all'esplorazione denominata order_items
. Abbina la dimensione inventory_id
da order_items
con la dimensione id
da inventory_item
. Abbina la dimensione order_id
da order_items
con la dimensione id
da order
. Questo valore viene specificato come segue:
explore: order_items {
join: order {
sql_on: ${order_items.order_id} = ${order.id} ;;
}
join: inventory_item {
sql_on: ${order_items.inventory_id} = ${inventory_item.id} ;;
}
}
Aspetti da tenere presenti
Utilizza required_joins
quando non è possibile usare la sintassi ${view_name.looker_dimension_name}
Quando fai riferimento ai campi in sql_on
utilizzando la sintassi ${view_name.looker_dimension_name}
, non devi preoccuparti di utilizzare required_joins
.
Tuttavia, alcuni modelli meno recenti utilizzano ancora la sintassi view_name.native_column_name
. In alcuni casi, non è possibile utilizzare la sintassi ${view_name.looker_dimension_name}
, ad esempio quando si vuole applicare codice SQL personalizzato.
In questi casi, potresti dover utilizzare required_joins
. Ne vengono discusse più dettagliatamente nella pagina della documentazione relativa al parametro required_joins
.