sql_always_having

Uso

explore: explore_name {
  sql_always_having: ${count} >= 100 ;;
}
Hierarquia
explore
sql_always_having
Valor padrão
Nenhum

Aceita
Uma condição SQL HAVING usando nomes de métricas e/ou nomes de colunas SQL

Regras especiais
Se você estiver referenciando um nome de coluna SQL em sql_always_having que faz parte de uma visualização unida, e não da análise detalhada, é importante usar o parâmetro always_join ou referenciar um nome de campo.

Definição

O sql_always_having permite aplicar uma restrição de consulta que os usuários não podem mudar. A restrição será inserida na cláusula HAVING do SQL subjacente gerado pelo Looker para todas as consultas na Análise em que sql_always_having é usado. Além das consultas executadas por usuários humanos, a restrição será aplicada a painéis, Looks programados e informações incorporadas que dependem dessa Análise.

A condição pode ser escrita em SQL puro, usando os nomes reais de tabela e coluna do banco de dados. Ele também pode usar referências do Looker, como:

  • ${view_name.SQL_TABLE_NAME}, que faz referência a uma visualização diferente do Looker ou a uma tabela derivada. SQL_TABLE_NAME nesta referência é uma string literal. Não é necessário substituir por nada.
  • ${view_name.field_name}, que faz referência a um campo do Looker. Usar esse método é melhor do que se referir diretamente às colunas SQL porque o Looker pode incluir automaticamente as junções necessárias.

Uma condição sql_always_having não é exibida para o usuário, a menos que ele analise o SQL das consultas criadas.

Exemplos

Impedir que os usuários vejam grupos com 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 os usuários vejam grupos com menos de US $1.000 de receita:

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

Impedir que os usuários vejam grupos com menos de 100 clientes:

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

Desafios comuns

Se você usa SQL bruto, talvez seja necessário usar always_join

Se você estiver referenciando um nome de coluna SQL em sql_always_having que faz parte de uma visualização unida em vez de fazer parte da análise detalhada, é importante usar o parâmetro always_join. Por exemplo,

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

Nesse caso, sql_always_having está fazendo referência a uma coluna da visualização customer unida, em vez da análise order. Como sql_always_having será aplicado a todas as consultas, é importante que customer também seja unido em todas elas.

Quando o Looker gera SQL para uma consulta, ele tenta criar o SQL mais limpo possível e usa apenas as junções necessárias para os campos selecionados por um usuário. Nesse caso, o Looker só faria a junção com customer se um usuário selecionasse um campo de cliente. Ao usar always_join, você pode forçar a junção a ocorrer, não importa o que aconteça.

Se, em vez de sql_always_having: SUM(customer.visits) >= 100, você usasse sql_always_having: ${customer.total_visits} >= 100, o Looker seria inteligente o suficiente para fazer a junção customer sem exigir que você usasse always_join. Por isso, recomendamos que você use referências de campo do Looker em vez de referências SQL brutas sempre que possível.

Use apenas um sql_always_having por análise detalhada

Só pode haver um sql_always_having em uma definição de explore. Coloque todo o comportamento desejado em um único sql_always_having usando AND e OR conforme necessário.

Informações importantes

Há um parâmetro semelhante para a cláusula WHERE do SQL.

Há um parâmetro muito semelhante ao sql_always_having chamado sql_always_where, que funciona da mesma forma, mas aplica condições à cláusula WHERE em vez da cláusula HAVING.

Se você quiser filtros que um usuário possa mudar, mas não remover, considere always_filter

Se você quiser forçar os usuários a usar um conjunto específico de filtros, mas em que o valor padrão possa ser alterado, tente always_filter.

Se você quiser filtros específicos do usuário que não podem ser alterados, considere usar access_filter.

Se você quiser que uma análise detalhada tenha filtros específicos para cada usuário e que não possam ser alterados de forma alguma, use access_filter.