SQL_On

Utilizzo

esplora: view_name_1 {
join: view_name_2 {
sql_on: ${view_name_1.id} = ${view_name_2.id} ;;
}
}

Gerarchia File modello explore join sql_on

Valore predefinito Nessuna Accetta 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 parametro required_joins. Questo concetto è spiegato in modo più dettagliato nella sezione Utilizzare required_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.