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 Explorar, según una cláusula ON de SQL que proporciones.

En 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.

Se puede unir una vista directamente a una exploración cuando se usa sql_on, o bien 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 código 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 ello 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 cambio, debe unirse a través de order. El código 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, solo necesitamos usar los nombres de vista correctos en nuestras referencias de campos. 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} 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 de ${view_name.looker_dimension_name} en esta página.

Uniones condicionales

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

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 basados en plantillas. 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 igual al valor de customer.creation_date_filter.

Usa las 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 búsqueda. 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 al Explorar llamado 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 pueda usar la sintaxis de ${view_name.looker_dimension_name}

Cuando haces referencia a campos en sql_on con la sintaxis de ${view_name.looker_dimension_name}, no tienes que 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 de ${view_name.looker_dimension_name}, por ejemplo, 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.