sql_on

Uso

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

Jerarquía Archivo del modelo explore join sql_on

Valor predeterminado Ninguna Acepta Una cláusula ON de SQL Reglas 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ámetro required_joins. Este concepto se explica con más detalle en la sección Usa required_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.