sql_always_having

Uso

explore: explore_name {
  sql_always_having: ${count} >= 100 ;;
}

Jerarquía Archivo del modelo explore sql_always_having

Valor predeterminado Ninguno Acepta Condición HAVING de SQL que usa nombres de medidas o nombres de columnas de SQL Reglas especiales Si haces referencia a un nombre de columna de SQL en sql_always_having que forma parte de una vista combinada, en lugar de formar parte de la Exploración, es importante que uses el parámetro always_join o que hagas referencia a un nombre de campo.

Definición

sql_always_having te permite aplicar una restricción de búsqueda que los usuarios no pueden cambiar. La restricción se insertará en la cláusula HAVING del SQL subyacente que genera Looker para todas las consultas en la Exploración en la que se usa sql_always_having. Además de las consultas que ejecutan los usuarios humanos, la restricción se aplicará a los paneles, las vistas planificadas y la información incorporada que dependa de esa exploración.

La condición se puede escribir en SQL puro, con los nombres reales de las tablas y las columnas de tu base de datos. También puede usar referencias de Looker, como las siguientes:

• ${view_name.SQL_TABLE_NAME}, que hace referencia a una vista de Looker diferente o a una tabla derivada Ten en cuenta que SQL_TABLE_NAME en esta referencia es una cadena literal, por lo que no necesitas reemplazarla con nada.
• ${view_name.field_name}, que hace referencia a un campo de Looker. Usar este método es mejor que hacer referencia a las columnas de SQL directamente, ya que Looker puede incluir automáticamente cualquier unión necesaria.

Una condición sql_always_having no se muestra al usuario, a menos que este examine el SQL subyacente de las consultas que crea.

Ejemplos

Impedir que los usuarios vean grupos con menos de 100 pedidos:

# Using Looker references
explore: order {
  sql_always_having: ${count} >= 100 ;;
}

# Using raw SQL
explore: order {
  sql_always_having: COUNT(*) >= 100 ;;
}

Impedir que los usuarios vean grupos con menos de USD 1,000 de ingresos:

explore: customer {
  sql_always_having: ${total_revenue} >= 1000 ;;
}

Evita que los usuarios vean grupos con menos de 100 clientes:

explore: order {
  sql_always_having: ${customer.count} >= 100 ;;
  join: customer {
    sql_on: ${order.customer_id} = ${customer.id} ;;
  }
}

Desafíos habituales

Si usas SQL sin procesar, es posible que debas usar always_join.

Si haces referencia a un nombre de columna de SQL en sql_always_having que forma parte de una vista unida en lugar de formar parte de la Exploración, es importante que uses el parámetro always_join. Considera el siguiente ejemplo:

explore: order {
  sql_always_having: SUM(customer.visits) >= 100 ;;
  join: customer {
    sql_on: ${order.customer_id} = ${customer.id} ;;
  }
}

En este caso, sql_always_having hace referencia a una columna de la vista customer unida, en lugar de la exploración order. Dado que sql_always_having se aplicará a cada consulta, es importante que customer también se una en cada consulta.

Cuando Looker genera SQL para una consulta, intenta crear el SQL más limpio posible y solo usará las uniones que sean necesarias para los campos que seleccione un usuario. En este caso, Looker solo uniría customer si un usuario seleccionara un campo de cliente. Si usas always_join, puedes forzar la unión sin importar qué suceda.

Si, en lugar de sql_always_having: SUM(customer.visits) >= 100, usaras sql_always_having: ${customer.total_visits} >= 100, Looker sería lo suficientemente inteligente como para realizar la unión customer sin necesidad de que uses always_join. Por este motivo, te recomendamos que uses referencias de campos de Looker en lugar de referencias de SQL sin procesar siempre que sea posible.

Solo se puede usar un sql_always_having por exploración.

Solo debe haber un sql_always_having en una definición de explore. Coloca todo el comportamiento deseado en un solo sql_always_having usando AND y OR según sea necesario.

Información importante

Existe un parámetro similar para la cláusula WHERE de SQL.

Hay un parámetro muy similar a sql_always_having llamado sql_always_where que funciona de la misma manera, pero aplica condiciones a la cláusula WHERE en lugar de a la cláusula HAVING.

Si quieres filtros que un usuario pueda cambiar, pero no quitar, considera usar always_filter.

Si quieres obligar a los usuarios a usar un conjunto específico de filtros, pero el valor predeterminado se puede cambiar, prueba con always_filter.

Si quieres filtros específicos para el usuario que no se puedan cambiar, considera usar access_filter.

Si deseas que una exploración tenga filtros específicos para cada usuario y que no se puedan cambiar de ninguna manera, puedes usar access_filter.