Utilizzo
sql_sempre_having: ${count} >= 100 ;;
}
Gerarchia
sql_always_having |
Valore predefinito
NessunaAccetta
Una condizione SQL HAVING che utilizza i nomi delle misurazioni e/o i nomi delle colonne SQLRegole 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 cheSQL_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
.