Uso
join: view_name_2 {
sql_on: ${view_name_1.id} = ${view_name_2.id} ;;
}
}
Hierarquia
sql_on |
Valor padrão
NenhumaAceita
Uma cláusula ON SQLRegras especiais
sql_on , sql_foreign_key e foreign_key não podem ser usados ao mesmo tempo dentro do mesmo join
|
Definição
sql_on
estabelece uma relação de mesclagem entre uma visualização e sua exploração, com base em uma cláusula ON
do SQL fornecida por você.
Para 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 banco de dados.
Uma visualização pode ser mesclada diretamente a uma exploração ao usar sql_on
ou pode ser mesclada com uma segunda visualização que já esteja associada a ela.
Veja um exemplo do primeiro caso em que uma visualização é mesclada diretamente ao recurso Explorar:
explore: order {
join: customer {
sql_on: ${order.customer_id} = ${customer.id} ;;
}
}
O SQL que o Looker geraria a partir desse LookML é:
SELECT ...
FROM order
LEFT JOIN customer
ON order.customer_id = customer.id
No segundo caso, uma visualização é mesclada a uma exploração por uma visualização intermediária que já está associada a ela. Veja um 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 vinculado diretamente a order_items
. Em vez disso, ele precisa ser mesclado por order
. O SQL que o Looker geraria a partir desse 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 fazer isso funcionar, é possível ver que precisamos apenas usar os nomes de visualização corretos em nossas referências de campo. Como customer
precisa se associar a um campo no order
, referenciamos ${order.customer_id}
.
Em alguns modelos mais antigos, é possível ver 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ê pode evitar a necessidade do parâmetrorequired_joins
. Esse conceito é explicado em mais detalhes na seção Usarrequired_joins
quando a sintaxe${view_name.looker_dimension_name}
não puder ser usada nesta página.
Mesclagens condicionais
Também é possível permitir que a entrada do usuário seja usada no sql_on
. Embora existam 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 neste tópico da comunidade.
Para adicionar entradas do usuário à condição de mesclagem, primeiro crie um filtro para a entrada. Esses tipos de filtro 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 deve ser interpretado para significar: definir customer.created_at
igual ao valor de customer.creation_date_filter
.
Como usar variáveis líquidas _in_query
, _is_selected
e _is_filtered
As variáveis líquidas _in_query
, _is_selected
e _is_filtered
podem ser úteis quando usadas com o parâmetro sql_on
. Eles permitem que você modifique as relações de mesclagem 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} =
{% 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 %} ;;
}
}
Examples
Mescle a visualização chamada customer
ao Explorar 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} ;;
}
}
Mescle a visualização customer
ao Explorar chamado order_items
pela visualização chamada order
. Combine a dimensão customer_id
de order
com a dimensão id
de customer
. Combine a dimensão order_id
de order_items
com a dimensão id
de order
. Isso seria especificado da seguinte maneira:
explore: order_items {
join: order {
sql_on: ${order_items.order_id} = ${order.id} ;;
}
join: customer {
sql_on: ${order.customer_id} = ${customer.id} ;;
}
}
Mescle as visualizações order
e inventory_items
ao order_items
. Combine a dimensão inventory_id
de order_items
com a dimensão id
de inventory_item
. Combine a dimensão order_id
de order_items
com a dimensão id
de order
. Isso seria especificado da seguinte maneira:
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 úteis
Usar required_joins
quando a sintaxe ${view_name.looker_dimension_name}
não puder ser usada
Ao referenciar campos em sql_on
com a sintaxe ${view_name.looker_dimension_name}
, você não precisa se preocupar em usar required_joins
.
No entanto, alguns modelos mais antigos ainda usam a sintaxe view_name.native_column_name
. Também há alguns casos em que não é possível usar a sintaxe ${view_name.looker_dimension_name}
, como quando você quer aplicar SQL personalizado.
Nessas situações, talvez seja necessário usar required_joins
. Eles são discutidos com mais detalhes na página de documentação do parâmetro required_joins
.