sql_on

Uso

explore: view_name_1 {
  join: view_name_2 {
    sql_on: ${view_name_1.id} = ${view_name_2.id} ;;
  }
}
Hierarquia
sql_on
Valor padrão
Nenhum

Aceita
Uma cláusula SQL ON

Regras especiais
sql_on, sql_foreign_key e foreign_key não podem ser usados ao mesmo tempo no mesmo join.

Definição

sql_on estabelece uma relação de junção entre uma visualização e a análise detalhada dela com base em uma cláusula SQL ON que você fornece.

Para o LookML, a ordem das condições em sql_on não importa. Portanto, sql_on: ${order.user_id} = ${user.id} ;; e sql_on: ${user.id} = ${order.user_id} ;; são equivalentes. É possível colocar as condições em qualquer ordem, a menos que a ordem seja relevante para o dialeto SQL do seu banco de dados.

Uma visualização pode ser combinada diretamente com uma análise usando sql_on ou por uma segunda visualização que já está combinada com essa análise.

Um exemplo do primeiro caso, em que uma visualização é unida diretamente à análise detalhada, tem esta aparência:

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

O SQL que o Looker geraria com base nesse LookML é:

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

No segundo caso, uma visualização é unida a uma Análise por uma visualização intermediária que já está unida a essa Análise. Por exemplo:

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

Aqui, customer não pode ser unido diretamente a order_items. Em vez disso, ele precisa ser unido usando order. O SQL que o Looker geraria com base nesse LookML é:

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

Para que isso funcione corretamente, basta usar os nomes de visualização corretos nas referências de campo. Como customer precisa se unir a um campo em order, fazemos referência a ${order.customer_id}.

Em alguns modelos mais antigos, talvez você veja campos referenciados com a sintaxe view_name.native_column_name. Embora isso ainda funcione, usar a sintaxe ${view_name.looker_dimension_name} tem uma vantagem importante: você evita a necessidade do parâmetro required_joins. Esse conceito é explicado em mais detalhes na seção Use required_joins quando a sintaxe ${view_name.looker_dimension_name} não puder ser usada nesta página.

Junções condicionais

Também é possível permitir que a entrada do usuário seja usada em sql_on. Embora haja vários motivos para fazer isso, otimizar a velocidade da consulta em bancos de dados MPP (como o Redshift) é um caso de uso importante, conforme descrito na postagem da comunidade Condições em cláusulas JOIN.

Para adicionar a entrada do usuário à condição de junção, primeiro crie um filtro para ela. Esses tipos de filtros são descritos em mais detalhes na página Filtros com modelo. A forma básica é:

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

Depois de adicionar um filtro para coletar a entrada do usuário, use-o no parâmetro sql_on desta forma:

{% condition view_name.filter_name %} view_name.dimension_name {% endcondition %}

Exemplo:

explore: order {
  join: customer {
    sql_on:
      ${order.customer_id} = ${customer.id} AND
      {% condition customer.creation_date_filter %} customer.created_at {% endcondition %} ;;
  }
}

Isso seria interpretado como: defina customer.created_at igual ao valor de customer.creation_date_filter.

Usar variáveis do Liquid _in_query, _is_selected e _is_filtered

As variáveis do Liquid _in_query, _is_selected e _is_filtered podem ser úteis quando usadas com o parâmetro sql_on. Eles permitem modificar as relações de junção com base nos campos que um usuário selecionou para a consulta. Exemplo:

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 %} ;;
  }
}

Exemplos

Faça a junção da visualização chamada customer à análise chamada order combinando a dimensão customer_id de order com a dimensão id de customer:

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

Faça a junção da visualização chamada customer à Análise chamada order_items usando a visualização order. Correlacione a dimensão customer_id de order com a dimensão id de customer. Correlacione a dimensão order_id de order_items com a dimensão id de order. Isso seria especificado da seguinte forma:

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

Junte as visualizações chamadas order e inventory_items à Análise chamada order_items. Correlacione a dimensão inventory_id de order_items com a dimensão id de inventory_item. Correlacione a dimensão order_id de order_items com a dimensão id de order. Isso seria especificado da seguinte forma:

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} ;;
  }
}

Informações importantes

Usar required_joins quando a sintaxe ${view_name.looker_dimension_name} não puder ser usada

Ao referenciar campos em sql_on usando a sintaxe ${view_name.looker_dimension_name}, não é necessário se preocupar em usar required_joins.

No entanto, alguns modelos mais antigos ainda usam a sintaxe view_name.native_column_name. Há também alguns casos em que não é possível usar a sintaxe ${view_name.looker_dimension_name}, como quando você quer aplicar SQL personalizado.

Nesses casos, talvez seja necessário usar required_joins. Elas são discutidas em mais detalhes na página de documentação do parâmetro required_joins.