Uso
join: view_name_2 {
sql_on: ${view_name_1.id} = ${view_name_2.id} ;;
}
}
Jerarquía
sql_on |
Valor predeterminado
NingunaAcepta
Una cláusula ON de SQLReglas especiales
No se pueden usar sql_on , sql_foreign_key y foreign_key al mismo tiempo dentro del mismo join .
|
Definición
sql_on
establece una relación de unión entre una vista y su Explorar, en función de una cláusula ON
de SQL que proporciones.
Para LookML, el orden de las condiciones en sql_on
no importa. Por lo tanto, sql_on: ${order.user_id} = ${user.id} ;;
y sql_on: ${user.id} = ${order.user_id} ;;
son equivalentes. Puedes colocar las condiciones en cualquier orden, a menos que el orden sea relevante para el dialecto SQL de tu base de datos.
Una vista se puede unir directamente a un elemento Explorar cuando se usa sql_on
o se puede unir mediante una segunda vista que ya esté unida a ese elemento.
Un ejemplo del primer caso, en el que una vista se une directamente a Explorar, se ve de la siguiente manera:
explore: order {
join: customer {
sql_on: ${order.customer_id} = ${customer.id} ;;
}
}
El SQL que Looker generaría a partir de este LookML es el siguiente:
SELECT ...
FROM order
LEFT JOIN customer
ON order.customer_id = customer.id
En el segundo caso, una vista se une a Explorar mediante una vista intermedia que ya está unida a esa. Un ejemplo sería:
explore: order_items {
join: order {
sql_on: ${order_items.order_id} = ${order.id} ;;
}
join: customer {
sql_on: ${order.customer_id} = ${customer.id} ;;
}
}
Aquí, customer
no se puede unir directamente a order_items
. En cambio, debe unirse mediante order
. El SQL que Looker generaría a partir de este LookML es el siguiente:
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 esto funcione correctamente, verás que solo necesitamos usar los nombres de vista correctos en nuestras referencias de campo. Como customer
necesita unirse a un campo en order
, hacemos referencia a ${order.customer_id}
.
En algunos modelos anteriores, es posible que veas campos a los que se hace referencia con la sintaxis
view_name.native_column_name
. Si bien esto aún funciona, el uso de la sintaxis${view_name.looker_dimension_name}
tiene una ventaja importante: puedes evitar la necesidad del parámetrorequired_joins
. Este concepto se explica con más detalle en la sección Usarequired_joins
cuando no se pueda usar la sintaxis${view_name.looker_dimension_name}
en esta página.
Uniones condicionales
También es posible permitir que se use la entrada del usuario en sql_on
. Aunque existen varias razones para querer hacerlo, optimizar la velocidad de consulta en bases de datos de MPP (como Redshift) es un caso práctico importante, como se describe en este tema de la Comunidad.
Para agregar entradas del usuario a tu condición de unión, primero deberás crear un filtro para su entrada. Estos tipos de filtros se describen con más detalle en nuestra página Filtros con plantilla. Su forma básica es:
view: view_name {
filter: filter_name {
type: number | datetime | date | string
}
}
Después de agregar un filtro para recopilar las entradas del usuario, puedes usarlo en tu parámetro sql_on
de la siguiente manera:
{% condition view_name.filter_name %} view_name.dimension_name {% endcondition %}
Por ejemplo:
explore: order {
join: customer {
sql_on:
${order.customer_id} = ${customer.id} AND
{% condition customer.creation_date_filter %} customer.created_at {% endcondition %} ;;
}
}
Esto se interpretaría como que el valor de customer.created_at
sea igual al valor de customer.creation_date_filter
.
Usa variables líquidas _in_query
, _is_selected
y _is_filtered
Las variables líquidas _in_query
, _is_selected
y _is_filtered
pueden ser útiles cuando se usan con el parámetro sql_on
. Pueden permitirle modificar relaciones de unión en función de los campos que un usuario seleccionó para su consulta. Por ejemplo:
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 %} ;;
}
}
Ejemplos
Únete a la vista llamada customer
con la pestaña Explorar llamada order
. Para ello, haz coincidir la dimensión customer_id
de order
con la dimensión id
de customer
:
explore: order {
join: customer {
sql_on: ${order.customer_id} = ${customer.id} ;;
}
}
Únete a la vista llamada customer
en la exploración llamada order_items
mediante la vista order
. Haz coincidir la dimensión customer_id
de order
con la dimensión id
de customer
. Haz coincidir la dimensión order_id
de order_items
con la dimensión id
de order
. Esto se especificaría de la siguiente manera:
explore: order_items {
join: order {
sql_on: ${order_items.order_id} = ${order.id} ;;
}
join: customer {
sql_on: ${order.customer_id} = ${customer.id} ;;
}
}
Une las vistas llamadas order
y inventory_items
a la pestaña Explorar order_items
. Haz coincidir la dimensión inventory_id
de order_items
con la dimensión id
de inventory_item
. Haz coincidir la dimensión order_id
de order_items
con la dimensión id
de order
. Esto se especificaría de la siguiente manera:
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} ;;
}
}
Qué debes saber
Usa required_joins
cuando no se pueda usar la sintaxis de ${view_name.looker_dimension_name}
Cuando hagas referencia a campos en sql_on
mediante la sintaxis ${view_name.looker_dimension_name}
, no tendrás que preocuparte por usar required_joins
.
Sin embargo, algunos modelos anteriores todavía usan la sintaxis view_name.native_column_name
. También hay algunos casos en los que no puedes usar la sintaxis ${view_name.looker_dimension_name}
, como cuando deseas aplicar SQL personalizado.
En estos casos, es posible que debas usar required_joins
. Se analizan con más detalle en la página de documentación del parámetro required_joins
.