sql_sempre_dove

Utilizzo

Explore: Explore_name {
sql_sempre_where: ${created_date} >= '2017-01-01' ;;
}

Gerarchia File modello explore sql_always_where

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

Definizione

sql_always_where consente di applicare una limitazione per le query che gli utenti non possono modificare. La restrizione verrà inserita nella clausola WHERE dell'SQL sottostante generato da Looker, per tutte le query in Explore in cui viene utilizzato sql_always_where. 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_where 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 gli ordini prima del 01/01/2012:

# Using Looker references
explore: order {
  sql_always_where: ${created_date} >= '2012-01-01' ;;
}

# Using raw SQL
explore: order {
  sql_always_where: DATE(created_time) >= '2012-01-01' ;;
}

Impedisci agli utenti di visualizzare le informazioni sui clienti per Periaptly Corporation:

explore: customer {
  sql_always_where: ${name} <> 'Periaptly Corporation' ;;
}

Impedisci agli utenti di esaminare gli ordini di Periaptly Corporation:

explore: order {
  sql_always_where: ${customer.name} <> 'Periaptly Corporation' ;;
  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_where che fa parte di una vista combinata, anziché Esplora, è importante utilizzare il parametro always_join. Considera questo esempio:

explore: order {
  sql_always_where: customer.name <> 'Periaptly Corporation' ;;
  join: customer {
    sql_on: ${order.customer_id} = ${customer.id} ;;
  }
}

In questo caso sql_always_where fa riferimento a una colonna della vista customer collegata, anziché a Esplora order. Poiché sql_always_where 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_where: customer.name <> 'Periaptly Corporation', utilizzassi sql_always_where: ${customer.name} <> 'Periaptly Corporation', 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_where per Esplora

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

Aspetti da tenere presenti

Esiste un parametro simile per la clausola SQL HAVING

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

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 non vuoi modificare i filtri specifici degli utenti, considera 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.