sql_on

Utilizzo

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

Gerarchia File del modello explore join sql_on

Valore predefinito Nessuno Accetta Una clausola ON SQL Regole speciali sql_on, sql_foreign_key e foreign_key non possono essere utilizzati contemporaneamente all'interno dello stesso join

Definizione

sql_on stabilisce una relazione di join tra una vista e la relativa esplorazione, in base a una clausola SQL ON che fornisci.

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 qualsiasi ordine, a meno che l'ordine non sia pertinente al dialetto SQL del tuo database.

Una visualizzazione può essere unita direttamente a un'esplorazione quando si utilizza sql_on oppure può essere unita tramite una seconda visualizzazione già unita all'esplorazione.

Un esempio del primo caso, in cui una vista viene unita direttamente all'Explore, è il seguente:

explore: order {
  join: customer {
    sql_on: ${order.customer_id} = ${customer.id} ;;
  }
}

Il codice SQL che Looker genererebbe da questo codice LookML è:

SELECT    ...
FROM      order
LEFT JOIN customer
ON        order.customer_id = customer.id

Nel secondo caso, una vista viene unita a un'esplorazione tramite una vista intermedia già unita a quell'esplorazione. Un esempio potrebbe essere:

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 unito direttamente a order_items. ma deve essere aggiunto tramite order. Il codice SQL che Looker genererebbe da questo codice LookML è:

SELECT    ...
FROM      order_items
LEFT JOIN order
ON        order_items.order_id = order.id
LEFT JOIN customer
ON        order.customer_id = customer.id

Per far funzionare correttamente questa operazione, devi utilizzare i nomi delle visualizzazioni corretti nei riferimenti ai campi. Poiché customer deve essere unito a un campo in order, facciamo 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. Sebbene questo metodo funzioni ancora, l'utilizzo della sintassi ${view_name.looker_dimension_name} presenta un vantaggio importante: puoi evitare la necessità del 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} di questa pagina.

Join condizionali

È anche possibile consentire l'utilizzo dell'input utente dell'utente in sql_on. Sebbene ci siano vari motivi per cui potresti volerlo fare, l'ottimizzazione della velocità delle query nei database MPP (come Redshift) è un caso d'uso importante, come descritto nel post della community Condizioni nelle clausole JOIN.

Per aggiungere l'input dell'utente alla condizione di unione, devi prima creare un filtro per l'input. Questi tipi di filtri sono descritti in modo più dettagliato nella pagina Filtri basati su modelli. La forma di base è:

view: view_name {
  filter: filter_name {
    type: number | datetime | date | string
  }
}

Dopo aver aggiunto un filtro per raccogliere l'input utente, utilizzalo nel parametro sql_on nel seguente 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 %} ;;
  }
}

Ciò significa impostare customer.created_at uguale al valore di customer.creation_date_filter.

Utilizzo delle variabili Liquid _in_query, _is_selected e _is_filtered

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 query. Ad esempio:

explore: dates {
  join: dynamic_order_counts {
    sql_on:
      ${dynamic_order_counts.period} =
      {% if dates.reporting_date._in_query %}
        ${dates.date_string}
      {% elsif dates.reporting_week._in_query %}
        ${dates.week_string}
      {% else %}
        ${dates.month_string}
      {% endif %} ;;
  }
}

Esempi

Unisci la visualizzazione denominata customer all'esplorazione denominata order abbinando la dimensione customer_id di order alla dimensione id di customer:

explore: order {
  join: customer {
    sql_on: ${order.customer_id} = ${customer.id} ;;
  }
}

Unisci la visualizzazione denominata customer all'esplorazione denominata order_items tramite la visualizzazione denominata order. Abbina la dimensione customer_id di order alla dimensione id di customer. Abbina la dimensione order_id di order_items alla dimensione id di order. che verrà 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 di order_items alla dimensione id di inventory_item. Abbina la dimensione order_id di order_items alla dimensione id di order. che verrà 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} ;;
  }
}

Cose da sapere

Utilizzare required_joins quando non è possibile utilizzare 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 precedenti utilizzano ancora la sintassi view_name.native_column_name. Esistono anche alcuni casi in cui non puoi utilizzare la sintassi ${view_name.looker_dimension_name}, ad esempio quando vuoi applicare SQL personalizzato.

In queste situazioni, potresti dover utilizzare required_joins. Questi parametri sono descritti in modo più dettagliato nella pagina della documentazione relativa al parametro required_joins.