sql_always_having

Penggunaan

explore: explore_name {
  sql_always_having: ${count} >= 100 ;;
}
Hierarki
sql_always_having
Nilai Default
Tidak ada

Menerima
Kondisi SQL HAVING menggunakan nama ukuran dan/atau nama kolom SQL

Aturan Khusus
Jika Anda mereferensikan nama kolom SQL di sql_always_having yang merupakan bagian dari tampilan gabungan, bukan bagian dari Eksplorasi, penting untuk menggunakan parameter always_join -- atau mereferensikan nama kolom

Definisi

sql_always_having memungkinkan Anda menerapkan batasan kueri yang tidak dapat diubah oleh pengguna. Batasan akan dimasukkan ke dalam klausa HAVING dari SQL pokok yang dihasilkan Looker, untuk semua kueri di Jelajah tempat sql_always_having digunakan. Selain kueri yang dijalankan oleh pengguna manusia, pembatasan ini juga akan berlaku untuk dasbor, Look terjadwal, dan informasi tersemat yang mengandalkan Eksplorasi tersebut.

Kondisi dapat ditulis dalam SQL murni, menggunakan nama tabel dan kolom sebenarnya dari database Anda. Anda juga dapat menggunakan referensi Looker seperti:

  • ${view_name.SQL_TABLE_NAME}, yang mereferensikan tampilan Looker lain atau tabel turunan. Perhatikan bahwa SQL_TABLE_NAME dalam referensi ini adalah string literal; Anda tidak perlu menggantinya dengan apa pun.
  • ${view_name.field_name}, yang mereferensikan kolom Looker. Menggunakan metode ini lebih baik daripada merujuk langsung ke kolom SQL karena Looker dapat otomatis menyertakan gabungan yang diperlukan.

Kondisi sql_always_having tidak ditampilkan kepada pengguna, kecuali jika mereka melihat SQL dasar dari kueri apa pun yang mereka buat.

Contoh

Mencegah pengguna melihat grup dengan kurang dari 100 pesanan:

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

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

Mencegah pengguna melihat grup dengan pendapatan kurang dari $1.000:

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

Mencegah pengguna melihat grup dengan kurang dari 100 pelanggan:

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

Tantangan umum

Jika menggunakan SQL mentah, Anda mungkin perlu menggunakan always_join

Jika Anda mereferensikan nama kolom SQL di sql_always_having yang merupakan bagian dari gabungan tabel virtual, bukan bagian dari Jelajah, penting untuk menggunakan parameter always_join. Perhatikan contoh berikut:

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

Dalam hal ini, sql_always_having merujuk ke kolom dari tampilan customer gabungan, bukan Eksplorasi order. Karena sql_always_having akan diterapkan ke setiap kueri, penting agar customer juga digabungkan di setiap kueri.

Saat membuat SQL untuk kueri, Looker akan mencoba membuat SQL yang paling bersih, dan hanya akan menggunakan gabungan yang diperlukan untuk kolom yang dipilih pengguna. Dalam hal ini, Looker hanya akan menggabungkan customer jika pengguna memilih kolom pelanggan. Dengan menggunakan always_join, Anda dapat memaksa gabungan terjadi apa pun yang terjadi.

Jika, alih-alih sql_always_having: SUM(customer.visits) >= 100, Anda menggunakan sql_always_having: ${customer.total_visits} >= 100, Looker akan cukup pintar untuk membuat gabungan customer tanpa mengharuskan Anda menggunakan always_join. Oleh karena itu, sebaiknya gunakan referensi kolom Looker, bukan referensi SQL mentah jika memungkinkan.

Hanya gunakan satu sql_always_having per Jelajahi

Anda hanya boleh memiliki satu sql_always_having dalam definisi explore. Masukkan semua perilaku yang diinginkan ke dalam satu sql_always_having dengan menggunakan AND dan OR sesuai kebutuhan.

Yang perlu diketahui

Ada parameter serupa untuk klausa WHERE SQL

Ada parameter yang sangat mirip dengan sql_always_having yang disebut sql_always_where yang berfungsi dengan cara yang sama, tetapi menerapkan kondisi ke klausa WHERE, bukan klausa HAVING.

Jika Anda menginginkan filter yang dapat diubah, tetapi tidak dapat dihapus oleh pengguna, pertimbangkan always_filter

Jika Anda ingin memaksa pengguna menggunakan serangkaian filter tertentu, tetapi nilai default dapat diubah, coba gunakan always_filter.

Jika Anda menginginkan filter khusus pengguna yang tidak dapat diubah, pertimbangkan access_filter

Jika Anda ingin Explore memiliki filter yang khusus untuk setiap pengguna, dan tidak dapat diubah dengan cara apa pun, Anda dapat menggunakan access_filter.