sql_always_having

Utilisation

explore: explore_name {
  sql_always_having: ${count} >= 100 ;;
}
Hiérarchie
explore
sql_always_having
Valeur par défaut
Aucun

Acceptation
Condition HAVING SQL utilisant des noms de mesures et/ou des noms de colonnes SQL

Règles spéciales
Si vous référencez un nom de colonne SQL dans sql_always_having qui fait partie d'une vue jointe plutôt que d'une exploration, il est important d'utiliser le paramètre always_join ou de référencer un nom de champ à la place.

Définition

sql_always_having vous permet d'appliquer une restriction de requête que les utilisateurs ne peuvent pas modifier. La restriction sera insérée dans la clause HAVING du code SQL sous-jacent généré par Looker pour toutes les requêtes sur l'exploration où sql_always_having est utilisé. Outre les requêtes exécutées par les humains, la restriction s'applique alors aux tableaux de bord, aux présentations planifiées et aux informations incorporées liées à cette exploration.

La condition peut être rédigée en SQL pur, en utilisant les noms réels des tables et des colonnes de votre base de données. Il peut également utiliser des références Looker telles que :

  • ${view_name.SQL_TABLE_NAME}, qui fait référence à une autre vue Looker ou à une table dérivée. Notez que dans cette référence, SQL_TABLE_NAME est une chaîne littérale, qu'il est donc inutile de remplacer.
  • ${view_name.field_name}, qui fait référence à un champ Looker. Cette méthode est préférable à la référence directe aux colonnes SQL, car Looker peut inclure automatiquement les jointures nécessaires.

Les conditions sql_always_having ne sont pas visibles par l'utilisateur, sauf s'il examine le code SQL sous-jacent des requêtes qu'il crée lui-même.

Exemples

Empêchez les utilisateurs de consulter les groupes comportant moins de 100 commandes :

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

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

Empêcher les utilisateurs de consulter les groupes dont les revenus sont inférieurs à 1 000 $ :

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

Empêchez les utilisateurs de consulter les groupes comportant moins de 100 clients :

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

Difficultés courantes

Si vous utilisez du code SQL brut, vous devrez peut-être utiliser always_join.

Si vous faites référence à un nom de colonne SQL dans sql_always_having qui fait partie d'une vue jointe plutôt que de l'exploration, il est important d'utiliser le paramètre always_join. Considérez l'exemple suivant :

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

Dans ce cas, sql_always_having fait référence à une colonne de la vue customer jointe, et non à l'exploration order. Étant donné que sql_always_having sera appliqué à chaque requête, il est important que customer soit également joint à chaque requête.

Lorsque Looker génère du code SQL pour une requête, il tente de créer le code SQL le plus propre possible et n'utilise que les jointures nécessaires pour les champs qu'un utilisateur sélectionne. Dans ce cas, Looker ne joindrait customer que si un utilisateur sélectionnait un champ client. En utilisant always_join, vous pouvez forcer la jointure à se produire quoi qu'il arrive.

Si vous utilisiez sql_always_having: ${customer.total_visits} >= 100 au lieu de sql_always_having: SUM(customer.visits) >= 100, Looker serait suffisamment intelligent pour effectuer la jointure customer sans que vous ayez à utiliser always_join. C'est pourquoi nous vous encourageons à utiliser des références de champ Looker plutôt que des références SQL brutes lorsque cela est possible.

N'utilisez qu'un seul sql_always_having par exploration.

Vous ne devez avoir qu'un seul sql_always_having dans une définition explore. Placez tous les comportements souhaités dans un seul sql_always_having en utilisant AND et OR si nécessaire.

Bon à savoir

Il existe un paramètre similaire pour la clause SQL WHERE.

Il existe un paramètre très semblable à sql_always_having, appelé sql_always_where, qui fonctionne de la même manière, mais qui applique des conditions à la clause WHERE au lieu de la clause HAVING.

Si vous souhaitez ajouter des filtres que l'utilisateur peut modifier, mais pas retirer, pensez à utiliser always_filter.

Si vous souhaitez forcer les utilisateurs à utiliser un ensemble spécifique de filtres, mais où la valeur par défaut peut être modifiée, essayez plutôt always_filter.

Si vous souhaitez des filtres spécifiques aux utilisateurs qui ne peuvent pas être modifiés, envisagez d'utiliser access_filter.

Si vous souhaitez qu'une exploration comporte des filtres spécifiques à chaque utilisateur et qui ne peuvent en aucun cas être modifiés, vous pouvez utiliser access_filter.