sql_on

Usage

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

היררכיה קובץ מודל explore join sql_on

ערך ברירת המחדל ללא אישור ONפסקה של SQL כללים מיוחדים יכול להיות שלא תוכלו להשתמש ב-sql_on, ב-sql_foreign_key וב-foreign_key בו-זמנית באותו join

הגדרה

‫sql_on יוצרת קשר בין תצוגה לבין ניתוח הנתונים שלה ב-Explore, על סמך פסקה של SQL‏ ON שאתם מספקים.

ב-LookML, סדר התנאים ב-sql_on לא משנה. לכן, הפונקציות sql_on: ${order.user_id} = ${user.id} ;; ו-sql_on: ${user.id} = ${order.user_id} ;; שוות ערך. אפשר להציב את התנאים בכל סדר, אלא אם הסדר רלוונטי לניב ה-SQL של מסד הנתונים.

אפשר לצרף תצוגה ישירות ל-Explore כשמשתמשים ב-sql_on, או לצרף אותה דרך תצוגה שנייה שכבר צורפה ל-Explore הזה.

דוגמה למקרה הראשון, שבו תצוגה מצורפת ישירות ל-Explore:

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

ה-SQL ש-Looker ייצור מ-LookML הזה הוא:

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

במקרה השני, תצוגה מצטרפת ל-Explore דרך תצוגת ביניים שכבר מצורפת ל-Explore הזה. לדוגמה:

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

במקרה הזה, אי אפשר להצטרף ישירות אל order_items.customer במקום זאת, צריך להצטרף אליו דרך order. קוד ה-SQL ש-Looker ייצור מ-LookML הזה הוא:

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

כדי שהפעולה הזו תתבצע בצורה תקינה, צריך להשתמש בשמות הנכונים של התצוגות בהפניות לשדות. מכיוון ש-customer צריך להצטרף לשדה ב-order, אנחנו מפנים ל-${order.customer_id}.

במודלים ישנים יותר, יכול להיות שתראו שדות עם הפניה באמצעות התחביר view_name.native_column_name. השיטה הזו עדיין עובדת, אבל לשימוש בתחביר ${view_name.looker_dimension_name} יש יתרון חשוב: לא צריך להשתמש בפרמטר required_joins. הסבר מפורט על המושג הזה מופיע בקטע שימוש ב-required_joins כשאי אפשר להשתמש בתחביר ${view_name.looker_dimension_name} בדף הזה.

שאילתות איחוד מותנות

אפשר גם לאפשר שימוש בקלט של משתמשים ב-sql_on. יש מגוון סיבות שבגללן כדאי לעשות את זה, אבל אחד מתרחישי השימוש העיקריים הוא אופטימיזציה של מהירות השאילתות במסדי נתונים של MPP (כמו Redshift), כפי שמתואר בפוסט בקהילה בנושא תנאים בסעיפי איחוד (join).

כדי להוסיף קלט של משתמשים לתנאי ההצטרפות, קודם צריך ליצור מסנן לקלט. הסוגים האלה של מסננים מתוארים בפירוט רב יותר בדף מסננים מבוססי-תבניות. הצורה הבסיסית שלהם היא:

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

אחרי שמוסיפים מסנן לאיסוף קלט של משתמשים, משתמשים בו בפרמטר sql_on כך:

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

לדוגמה:

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

המשמעות של הפעולה הזו היא: הערך של customer.created_at שווה לערך של customer.creation_date_filter.

שימוש במשתני Liquid‏ _in_query,‏ _is_selected ו-_is_filtered

משתני Liquid‏ _in_query, _is_selected ו-_is_filtered יכולים להיות שימושיים כשמשתמשים בהם עם הפרמטר sql_on. הם יכולים לאפשר לכם לשנות את יחסי הצירוף על סמך השדות שהמשתמש בחר לשאילתה שלו. לדוגמה:

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 %} ;;
  }
}

דוגמאות

מצטרפים לתצוגה שנקראת customer לניתוח שנקרא order על ידי התאמה בין המאפיין customer_id מ-order לבין המאפיין id מ-customer:

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

מצטרפים לתצוגה שנקראת customer לניתוח שנקרא order_items דרך התצוגה שנקראת order. התאמה בין המאפיין customer_id מ-order לבין המאפיין id מ-customer. התאמה בין המאפיין order_id מ-order_items לבין המאפיין id מ-order. ההגדרה תהיה כזו:

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

מצטרפים לתצוגות המפורטות שנקראות order ו-inventory_items ב-Explore שנקרא order_items. התאמה בין המאפיין inventory_id מ-order_items לבין המאפיין id מ-inventory_item. התאמה בין המאפיין order_id מ-order_items לבין המאפיין id מ-order. ההגדרה תהיה כזו:

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} ;;
  }
}

חשוב לדעת

שימוש ב-required_joins כשאי אפשר להשתמש בתחביר של ${view_name.looker_dimension_name}

כשמפנים לשדות ב-sql_on באמצעות התחביר ${view_name.looker_dimension_name}, לא צריך להשתמש ב-required_joins.

עם זאת, יש מודלים ישנים יותר שעדיין משתמשים בתחביר view_name.native_column_name. יש גם מקרים שבהם אי אפשר להשתמש בתחביר ${view_name.looker_dimension_name}, למשל כשרוצים להחיל SQL מותאם אישית.

במקרים כאלה, יכול להיות שתצטרכו להשתמש ב-required_joins. פרטים נוספים מופיעים בדף התיעוד של הפרמטר required_joins.