Utilizzo
explore: explore_name {
always_join: [
view_name,
view_name,
...
]
}
|
Gerarchia
always_join |
Valore predefinito
Nessuno
Accetta
Parentesi quadre contenenti un elenco di nomi delle visualizzazioni separati da virgole
Regole speciali
Prima di utilizzarla in always_join, devi unire una visualizzazione a explore
|
Definizione
always_join impone l'inclusione di uno o più join nell'SQL generato da Looker, anche se l'utente non ha selezionato un campo da quella vista unita. Potrebbero essere necessari più join utilizzando un elenco separato da virgole come [view_name_a, view_name_b, etc].
Quando Looker genera SQL per una query, tenta di creare l'SQL più pulito possibile e utilizza solo i join necessari per i campi selezionati da un utente. Utilizzando always_join, puoi forzare le unioni a prescindere da tutto.
always_join può essere utile quando viene eseguita un'unione con il parametro type e l'unione non è un LEFT JOIN. In una situazione del genere, il join potrebbe essere fondamentale per limitare correttamente le righe restituite.
Esempi
Assicurati che member sia sempre unito a event, anche se l'utente non sceglie un campo da member. In questo modo, i risultati vengono limitati agli eventi generati dai membri:
explore: event {
always_join: [member]
join: member {
sql_on: ${event.member_id} = ${member.id} ;;
type: inner
}
}
Assicurati che member e payment siano sempre uniti a event, anche se l'utente non sceglie un campo da una di queste visualizzazioni. In questo modo, i risultati vengono limitati agli eventi generati dagli abbonati per i quali è già stato effettuato il pagamento:
explore: event {
always_join: [member, payment]
join: member {
sql_on: ${event.member_id} = ${member.id} ;;
type: inner
}
join: payment {
sql_on: ${member.payment_id} = ${payment.id} ;;
type: inner
}
}
Sfide comuni
Una vista deve essere unita a un'esplorazione prima di poter essere referenziata in always_join
Per inserire una visualizzazione in always_join, assicurati che sia unita all'esplorazione in cui viene utilizzato always_join. Ad esempio, questo non funzionerà:
explore: event {
always_join: [member]
}
Qui la visualizzazione member non è stata unita a event, quindi non è disponibile per l'utilizzo in always_join.
Cose da sapere
Se possibile, non applicare la logica di business nei join
L'approccio standard di Looker per l'unione consiste nell'utilizzare un LEFT JOIN quando possibile. Negli esempi precedenti, evitiamo un LEFT JOIN in modo che la logica di business possa essere applicata all'interno del join stesso. In uno degli esempi abbiamo creato un'esplorazione che includeva solo gli eventi associati ai membri:
explore: event {
always_join: [member]
join: member {
sql_on: ${event.member_id} = ${member.id} ;;
type: inner
}
}
Il modo migliore per eseguire questa operazione in Looker è utilizzare un LEFT JOIN per unire facilmente i dati sugli eventi e i dati dei membri:
explore: event {
join: member {
sql_on: ${event.member_id} = ${member.id} ;;
}
}
Poi potresti creare una dimensione che puoi impostare su sì o no per esaminare solo gli eventi degli abbonati:
dimension: is_member_event {
type: yesno
sql: ${member.id} IS NOT NULL ;;
}
Questo approccio offre agli utenti la flessibilità di esaminare tutti gli eventi o solo quelli relativi agli abbonati. Non hai forzato gli utenti a visualizzare solo gli eventi dei membri tramite l'unione.
Quando un'esplorazione include always_join, il valore predefinito di full_suggestions passa a yes
Quando un'esplorazione include il parametro always_join, il valore predefinito di full_suggestions passa a yes. In questo modo, la query dei suggerimenti viene eseguita utilizzando la logica di Explore, il che significa che always_join verrà applicato per restringere i suggerimenti restituiti, limitando l'elenco dei suggerimenti solo ai dati a cui l'utente deve avere accesso.
Se imposti manualmente full_suggestions su no, la query di suggerimento del filtro non verrà eseguita.