sql_always_having

Usage

explore: explore_name {
  sql_always_having: ${count} >= 100 ;;
}

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

ערך ברירת המחדל ללא מקבל תנאי SQL HAVING באמצעות שמות של מדדים ו/או שמות של עמודות SQL כללים מיוחדים אם אתם מפנים לשם של עמודת SQL ב-sql_always_having שהיא חלק מתצוגה שצורף אליה תוכן, ולא חלק מהניתוח, חשוב להשתמש בפרמטר always_join או להפנות לשם של שדה

הגדרה

sql_always_having מאפשרת לכם להחיל הגבלת שאילתה שהמשתמשים לא יכולים לשנות. ההגבלה תוחדר לסעיף HAVING של ה-SQL הבסיסי שנוצר על ידי Looker, לכל השאילתות בניתוח שבהן נעשה שימוש ב-sql_always_having. בנוסף לשאילתות שמריצים משתמשים אנושיים, ההגבלה תחול על מרכזי בקרה, על תצוגות Look מתוזמנות ועל מידע מוטמע שמסתמך על התכונה 'ניתוח נתונים'.

אפשר לכתוב את התנאי ב-SQL טהור, באמצעות השמות האמיתיים של הטבלה והעמודות במסד הנתונים. הוא יכול גם להשתמש בהפניות של Looker כמו:

• ‫${view_name.SQL_TABLE_NAME}, שמפנה לתצוגה אחרת ב-Looker או לטבלה נגזרת. הערה: SQL_TABLE_NAME בהפניה הזו היא מחרוזת מילולית, ולא צריך להחליף אותה בשום דבר.
• ${view_name.field_name}, שמפנה לשדה Looker. השימוש בשיטה הזו עדיף על הפניה ישירות לעמודות SQL, כי Looker יכול לכלול באופן אוטומטי את כל שאילתות האיחוד (join) הנדרשות.

sql_always_having תנאי לא מוצג למשתמש, אלא אם הוא בודק את ה-SQL הבסיסי של שאילתות שהוא יוצר.

דוגמאות

משתמשים לא יכולים לראות קבוצות עם פחות מ-100 הזמנות:

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

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

למנוע ממשתמשים לראות קבוצות עם הכנסות של פחות מ-1,000$:

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

משתמשים לא יוכלו לראות קבוצות עם פחות מ-100 לקוחות:

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

אתגרים נפוצים

אם אתם משתמשים ב-SQL גולמי, יכול להיות שתצטרכו להשתמש ב-always_join

אם אתם מפנים לשם של עמודת SQL ב-sql_always_having שהיא חלק מתצוגה משולבת ולא חלק מהניתוח, חשוב להשתמש בפרמטר always_join. דוגמה:

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

במקרה הזה, sql_always_having מפנה לעמודה מהתצוגה המצורפת customer, במקום ל-Explore order. מכיוון שהמסנן sql_always_having יוחל על כל שאילתה, חשוב גם להוסיף את customer לכל שאילתה.

כש-Looker יוצר SQL לשאילתה, הוא מנסה ליצור את ה-SQL הכי נקי שאפשר, וישתמש רק בצירופים שנדרשים לשדות שהמשתמש בוחר. במקרה כזה, Looker יצטרף ל-customer רק אם משתמש יבחר שדה לקוח. השימוש ב-always_join מאפשר לכם לכפות את ההצטרפות ללא קשר למה שקורה.

אם במקום sql_always_having: SUM(customer.visits) >= 100 השתמשתם ב-sql_always_having: ${customer.total_visits} >= 100, מערכת Looker תהיה חכמה מספיק כדי לבצע את הצירוף customer בלי שתצטרכו להשתמש ב-always_join. לכן, מומלץ להשתמש בהפניות לשדות של Looker במקום בהפניות ל-SQL גולמי, כשאפשר.

אפשר להשתמש רק ב-sql_always_having אחד בכל ניתוח

צריך להגדיר רק sql_always_having אחד בהגדרה של explore. כדי להגדיר את כל ההתנהגויות הרצויות ב-sql_always_having אחד, משתמשים ב-AND וב-OR לפי הצורך.

חשוב לדעת

יש פרמטר דומה לסעיף WHERE ב-SQL

קיים פרמטר דומה מאוד ל-sql_always_having שנקרא sql_always_where. הוא פועל באותו אופן, אבל הוא מחיל תנאים על פסקה WHERE במקום על פסקה HAVING.

אם רוצים להגדיר מסננים שהמשתמש יכול לשנות אבל לא להסיר, כדאי לשקול always_filter

אם אתם רוצים לחייב את המשתמשים להשתמש בקבוצה מסוימת של מסננים, אבל לאפשר להם לשנות את ערך ברירת המחדל, כדאי לנסות את האפשרות always_filter.

אם אתם רוצים מסננים ספציפיים למשתמשים שלא ניתן לשנות, כדאי להשתמש ב-access_filter

אם רוצים שבדוח Explore יהיו מסננים שספציפיים לכל משתמש, ושאי אפשר לשנות אותם בשום צורה, אפשר להשתמש בaccess_filter.