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 Ninguno Acepta Una cláusula ON de SQL Reglas especiales sql_on, sql_foreign_key y foreign_key no se pueden usar al mismo tiempo dentro del mismo join.

Definición

sql_on establece una relación de unión entre una vista y su exploración, según una cláusula ON de SQL que proporciones.

En LookML, no importa el orden de las condiciones en sql_on. 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 de SQL de tu base de datos.

Se puede unir una vista directamente a una exploración cuando se usa sql_on, o se puede unir a través de una segunda vista que ya está unida a esa exploración.

Un ejemplo del primer caso, en el que una vista se une directamente a la exploración, 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 una exploración a través de una vista intermedia que ya está unida a esa exploración. Un ejemplo de eso sería el siguiente:

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 su lugar, debe unirse a través de 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, puedes ver que solo necesitamos usar los nombres de vista correctos en nuestras referencias de campo. Como customer debe unirse a un campo en order, hacemos referencia a ${order.customer_id}.

En algunos modelos más antiguos, es posible que veas campos a los que se hace referencia con la sintaxis view_name.native_column_name. Si bien esto sigue funcionando, usar la sintaxis ${view_name.looker_dimension_name} en su lugar tiene una ventaja importante: puedes evitar la necesidad del required_joins parámetro. Este concepto se explica con más detalle en la sección Usa required_joins cuando no se puede usar la sintaxis ${view_name.looker_dimension_name} de esta página.

Uniones condicionales

También es posible permitir que la entrada del usuario se use en sql_on. Aunque existen varios motivos por los que puedes querer hacer esto, optimizar la velocidad de las consultas en bases de datos MPP (como Redshift) es un caso de uso importante, como se describe en la publicación de Comunidad Condiciones en cláusulas de unión.

Para agregar la entrada 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 parámetros. Su forma básica es la siguiente:

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

Una vez que agregues un filtro para recopilar la entrada del usuario, úsalo 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 de la siguiente manera: establece customer.created_at en el valor de customer.creation_date_filter.

Usa variables de Liquid _in_query, _is_selected y _is_filtered

Las variables de Liquid _in_query, _is_selected y _is_filtered pueden ser útiles cuando se usan con el parámetro sql_on. Pueden permitirte modificar las 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} =
      {% if dates.reporting_date._in_query %}
        ${dates.date_string}
      {% elsif dates.reporting_week._in_query %}
        ${dates.week_string}
      {% else %}
        ${dates.month_string}
      {% endif %} ;;
  }
}

Ejemplos

Une la vista llamada customer a la exploración llamada order haciendo 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} ;;
  }
}

Une la vista llamada customer a la exploración llamada order_items a través de la vista llamada 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 exploración llamada 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} ;;
  }
}

Información importante

Usa required_joins cuando no se puede usar la sintaxis ${view_name.looker_dimension_name}

Cuando haces referencia a campos en sql_on con la sintaxis ${view_name.looker_dimension_name}, no debes preocuparte por usar required_joins.

Sin embargo, algunos modelos más antiguos aún 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 estas situaciones, 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.