sql_sempre_having

Utilizzo

Explore: Explore_name {
sql_sempre_having: ${count} >= 100 ;;
}

Gerarchia File modello explore sql_always_having

Valore predefinito Nessuna Accetta Una condizione SQL HAVING che utilizza i nomi delle misurazioni e/o i nomi delle colonne SQL Regole speciali Se fai riferimento a un nome di colonna SQL in sql_always_having che fa parte di una vista unita, anziché fare parte di Esplora, è importante utilizzare il parametro always_join oppure fare riferimento al nome di un campo

Definizione

sql_always_having consente di applicare una limitazione per le query che gli utenti non possono modificare. La restrizione verrà inserita nella clausola HAVING dell'SQL sottostante generato da Looker, per tutte le query in Explore in cui viene utilizzato sql_always_having. Oltre alle query eseguite da utenti, la limitazione si applica alle dashboard, ai Look pianificati e alle informazioni incorporate che si basano su Esplora.

La condizione può essere scritta in SQL puro, utilizzando i nomi effettivi di tabelle e colonne del database. Può anche utilizzare riferimenti a Looker come:

• ${view_name.SQL_TABLE_NAME}, che fa riferimento a un'altra visualizzazione di Looker o a una tabella derivata. Tieni presente che SQL_TABLE_NAME in questo riferimento è una stringa letterale; non è necessario sostituirla con nulla.
• ${view_name.field_name}, che fa riferimento a un campo di Looker. Utilizzare questo metodo è meglio che fare riferimento direttamente alle colonne SQL perché Looker può includere automaticamente tutti gli join necessari.

Una condizione sql_always_having non viene mostrata all'utente, a meno che non esamini il codice SQL sottostante di eventuali query che crea.

Esempi

Impedisci agli utenti di esaminare i gruppi con meno di 100 ordini:

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

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

Impedisci agli utenti di esaminare i gruppi con entrate inferiori a 1000 $:

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

Impedisci agli utenti di esaminare i gruppi con meno di 100 clienti:

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

Sfide comuni

Se usi SQL non elaborato, potresti dover utilizzare always_join

Se fai riferimento a un nome di colonna SQL in sql_always_having che fa parte di una vista unita anziché di Esplora, è importante utilizzare il parametro always_join. Considera questo esempio:

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

In questo caso sql_always_having fa riferimento a una colonna della vista customer collegata, anziché a Esplora order. Poiché sql_always_having verrà applicato a ogni query, è importante che customer venga associato a ogni query.

Quando Looker genera SQL per una query, tenta di creare il codice SQL più pulito possibile e utilizzerà solo i join necessari per i campi selezionati dall'utente. In questo caso, Looker si unirà a customer solo se un utente ha selezionato un campo cliente. Utilizzando always_join, puoi forzare l'unione a partecipare in ogni caso.

Se, invece di sql_always_having: SUM(customer.visits) >= 100, utilizzassi sql_always_having: ${customer.total_visits} >= 100, Looker sarebbe abbastanza smart da partecipare all'customer senza dover utilizzare always_join. Per questo motivo, quando possibile, ti invitiamo a utilizzare i riferimenti ai campi di Looker anziché i riferimenti SQL non elaborati.

Utilizza una sola sql_always_having per Esplora

Ogni definizione in explore deve avere un solo sql_always_having. Raggruppa tutti i comportamenti desiderati in un singolo sql_always_having utilizzando AND e OR in base alle necessità.

Aspetti da tenere presenti

Esiste un parametro simile per la clausola SQL WHERE

Esiste un parametro molto simile a sql_always_having, chiamato sql_always_where, che funziona allo stesso modo, ma applica condizioni alla clausola WHERE anziché alla clausola HAVING.

Se vuoi che i filtri possano essere modificati da un utente, ma non da rimuovere, valuta la possibilità di always_filter

Se vuoi forzare gli utenti a utilizzare un insieme specifico di filtri, ma in cui è possibile modificare il valore predefinito, prova invece always_filter.

Se vuoi che i filtri specifici degli utenti non possano essere modificati, valuta access_filter

Se vuoi che un filtro Esplora abbia filtri specifici per ogni utente e non possa essere modificato in nessun modo, puoi utilizzare access_filter.