sql_on

Penggunaan

explore: view_name_1 {
  join: view_name_2 {
    sql_on: ${view_name_1.id} = ${view_name_2.id} ;;
  }
}

Hierarki File Model explore join sql_on

Nilai Default Tidak ada Menerima Klausul ON SQL Aturan Khusus sql_on, sql_foreign_key, dan foreign_key tidak boleh digunakan secara bersamaan dalam join yang sama

Definisi

sql_on menetapkan hubungan gabungan antara tampilan dan Eksplorasinya, berdasarkan klausul ON SQL yang Anda berikan.

Untuk LookML, urutan kondisi dalam sql_on tidak penting. Jadi, sql_on: ${order.user_id} = ${user.id} ;; dan sql_on: ${user.id} = ${order.user_id} ;; setara. Anda dapat menempatkan kondisi dalam urutan apa pun, kecuali jika urutan tersebut relevan dengan dialek SQL database Anda.

Tampilan dapat digabungkan langsung ke Eksplorasi saat menggunakan sql_on, atau dapat digabungkan melalui tampilan kedua yang sudah digabungkan ke Eksplorasi tersebut.

Contoh kasus pertama, saat tampilan digabungkan langsung ke Eksplorasi, terlihat seperti ini:

explore: order {
  join: customer {
    sql_on: ${order.customer_id} = ${customer.id} ;;
  }
}

SQL yang akan dihasilkan Looker dari LookML ini adalah:

SELECT    ...
FROM      order
LEFT JOIN customer
ON        order.customer_id = customer.id

Dalam kasus kedua, tampilan digabungkan ke Eksplorasi melalui tampilan perantara yang sudah digabungkan ke Eksplorasi tersebut. Contohnya adalah:

explore: order_items {
  join: order {
    sql_on: ${order_items.order_id} = ${order.id} ;;
  }
  join: customer {
    sql_on: ${order.customer_id} = ${customer.id} ;;
  }
}

Di sini, customer tidak dapat digabungkan langsung ke order_items. Sebagai gantinya, kolom ini harus digabungkan melalui order. SQL yang akan dihasilkan Looker dari LookML ini adalah:

SELECT    ...
FROM      order_items
LEFT JOIN order
ON        order_items.order_id = order.id
LEFT JOIN customer
ON        order.customer_id = customer.id

Agar fungsi ini berfungsi dengan benar, Anda dapat melihat bahwa kita hanya perlu menggunakan nama tampilan yang benar dalam referensi kolom. Karena customer harus digabungkan ke kolom di order, kita mereferensikan ${order.customer_id}.

Di beberapa model lama, Anda mungkin melihat kolom yang direferensikan dengan sintaksis view_name.native_column_name. Meskipun masih berfungsi, menggunakan sintaksis ${view_name.looker_dimension_name} memiliki keunggulan penting: Anda dapat menghindari kebutuhan parameter required_joins. Konsep ini dijelaskan lebih mendetail di bagian Menggunakan required_joins saat sintaksis ${view_name.looker_dimension_name} tidak dapat digunakan di halaman ini.

Gabungan bersyarat

Anda juga dapat mengizinkan input pengguna digunakan di sql_on. Meskipun ada berbagai alasan mengapa Anda mungkin ingin melakukannya, mengoptimalkan kecepatan kueri di database MPP (seperti Redshift) adalah kasus penggunaan utama, seperti yang dijelaskan dalam postingan Komunitas Kondisi dalam Klausul Gabungan.

Untuk menambahkan input pengguna ke kondisi gabungan, Anda harus membuat filter untuk inputnya terlebih dahulu. Jenis filter ini dijelaskan lebih mendetail di halaman Filter Bertemplate. Bentuk dasarnya adalah:

view: view_name {
  filter: filter_name {
    type: number | datetime | date | string
  }
}

Setelah menambahkan filter untuk mengumpulkan input pengguna, Anda menggunakannya dalam parameter sql_on seperti ini:

{% condition view_name.filter_name %} view_name.dimension_name {% endcondition %}

Contoh:

explore: order {
  join: customer {
    sql_on:
      ${order.customer_id} = ${customer.id} AND
      {% condition customer.creation_date_filter %} customer.created_at {% endcondition %} ;;
  }
}

Hal ini akan ditafsirkan sebagai: menetapkan customer.created_at sama dengan nilai dari customer.creation_date_filter.

Menggunakan variabel Liquid _in_query, _is_selected, dan _is_filtered

Variabel Liquid _in_query, _is_selected, dan _is_filtered dapat berguna saat digunakan dengan parameter sql_on. Variabel ini dapat memungkinkan Anda mengubah hubungan gabungan berdasarkan kolom yang telah dipilih pengguna untuk kuerinya. Contoh:

explore: dates {
  join: dynamic_order_counts {
    sql_on:
      ${dynamic_order_counts.period} =
      {% if dates.reporting_date._in_query %}
        ${dates.date_string}
      {% elsif dates.reporting_week._in_query %}
        ${dates.week_string}
      {% else %}
        ${dates.month_string}
      {% endif %} ;;
  }
}

Contoh

Gabungkan tampilan bernama customer ke Eksplorasi bernama order dengan mencocokkan dimensi customer_id dari order dengan dimensi id dari customer:

explore: order {
  join: customer {
    sql_on: ${order.customer_id} = ${customer.id} ;;
  }
}

Gabungkan tampilan bernama customer ke Eksplorasi bernama order_items melalui tampilan bernama order. Cocokkan dimensi customer_id dari order dengan dimensi id dari customer. Cocokkan dimensi order_id dari order_items dengan dimensi id dari order. Hal ini akan ditentukan sebagai berikut:

explore: order_items {
  join: order {
    sql_on: ${order_items.order_id} = ${order.id} ;;
  }
  join: customer {
    sql_on: ${order.customer_id} = ${customer.id} ;;
  }
}

Gabungkan tampilan bernama order dan inventory_items ke Eksplorasi bernama order_items. Cocokkan dimensi inventory_id dari order_items dengan dimensi id dari inventory_item. Cocokkan dimensi order_id dari order_items dengan dimensi id dari order. Hal ini akan ditentukan sebagai berikut:

explore: order_items {
  join: order {
    sql_on: ${order_items.order_id} = ${order.id} ;;
  }
  join: inventory_item {
    sql_on: ${order_items.inventory_id} = ${inventory_item.id} ;;
  }
}

Yang perlu diketahui

Menggunakan required_joins saat sintaksis ${view_name.looker_dimension_name} tidak dapat digunakan

Saat mereferensikan kolom di sql_on menggunakan sintaksis ${view_name.looker_dimension_name}, Anda tidak perlu khawatir menggunakan required_joins.

Namun, beberapa model lama masih menggunakan sintaksis view_name.native_column_name. Ada juga beberapa kasus saat Anda tidak dapat menggunakan sintaksis ${view_name.looker_dimension_name}, seperti saat Anda ingin menerapkan SQL kustom.

Dalam situasi ini, Anda mungkin perlu menggunakan required_joins. Hal ini dibahas lebih mendetail di halaman dokumentasi parameter required_joins.