sql_immer_haben

Nutzung

Explore: Name_Name {
sql_Always_have: ${count} >= 100 ;;
}

Hierarchie Modelldatei explore sql_always_having

Standardwert Keine Akzeptiert Eine SQL-HAVING-Bedingung mit Messwertnamen und/oder SQL-Spaltennamen Sonderregeln Wenn Sie in sql_always_having auf einen SQL-Spaltennamen verweisen, der Teil einer verknüpften Ansicht und nicht Teil der Funktion „Erkunden“ ist, ist es wichtig, dass Sie den Parameter always_join verwenden oder auf einen Feldnamen verweisen

Definition

Mit sql_always_having können Sie eine Abfrageeinschränkung anwenden, die Nutzer nicht ändern können. Die Einschränkung wird für alle Abfragen in der explorativen Datenanalyse, in der sql_always_having verwendet wird, in die HAVING-Klausel des zugrunde liegenden SQL-Codes eingefügt. Neben den von menschlichen Benutzern ausgeführten Abfragen gilt diese Beschränkung für Dashboards, geplante Looks und eingebettete Informationen, die auf dieses Explore zurückgreifen.

Die Bedingung kann in reinem SQL mit den tatsächlichen Tabellen- und Spaltennamen Ihrer Datenbank geschrieben werden. Es kann auch Looker-Referenzen wie die folgenden verwenden:

• ${view_name.SQL_TABLE_NAME}, die auf eine andere Looker-Ansicht oder eine abgeleitete Tabelle verweist. Beachten Sie, dass SQL_TABLE_NAME in dieser Referenz ein literaler String ist. Sie müssen nicht durch etwas ersetzt werden.
• ${view_name.field_name}, die auf ein Looker-Feld verweist. Diese Methode ist besser als direkte Verweise auf SQL-Spalten, da Looker automatisch alle erforderlichen Joins hinzufügen kann.

Eine sql_always_having-Bedingung wird dem Nutzer nur dann angezeigt, wenn er sich den zugrunde liegenden SQL-Code aller von ihm erstellten Abfragen ansieht.

Beispiele

Verhindern, dass Nutzer Gruppen mit weniger als 100 Bestellungen aufrufen:

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

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

Verhindern,dass Nutzer Gruppen mit weniger als 1.000 $Umsatz sehen:

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

Verhindern, dass Nutzer Gruppen mit weniger als 100 Kunden ansehen:

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

Häufige Herausforderungen

Wenn Sie Raw-SQL verwenden, müssen Sie möglicherweise always_join verwenden

Wenn Sie in sql_always_having auf einen SQL-Spaltennamen verweisen, der Teil einer verknüpften Ansicht und nicht Teil der Funktion „Erkunden“ ist, ist es wichtig, den Parameter always_join zu verwenden. Betrachten Sie dieses Beispiel:

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

In diesem Fall verweist sql_always_having auf eine Spalte aus der verknüpften customer-Ansicht statt auf die Funktion order „Erkunden“. Da sql_always_having auf jede Abfrage angewendet wird, muss customer auch in jeder Abfrage enthalten sein.

Wenn Looker SQL für eine Abfrage generiert, wird versucht, einen möglichst klaren SQL-Code zu erstellen. Dabei werden nur Joins verwendet, die für die vom Nutzer ausgewählten Felder erforderlich sind. In diesem Fall würde Looker nur customer beitreten, wenn ein Nutzer ein Kundenfeld ausgewählt hat. Mit always_join können Sie erzwingen, dass die Join-Operation ausgeführt wird, unabhängig davon, was passiert.

Wenn Sie anstelle von sql_always_having: SUM(customer.visits) >= 100 sql_always_having: ${customer.total_visits} >= 100 verwendet haben, wäre Looker intelligent genug, um customer zusammenzuführen, ohne dass Sie always_join verwenden müssen. Aus diesem Grund empfehlen wir, nach Möglichkeit Looker-Feldverweise anstelle von unbearbeiteten SQL-Referenzen zu verwenden.

Nur ein sql_always_having pro Erkunden

Sie sollten nur eine sql_always_having in einer explore-Definition haben. Verschieben Sie das gewünschte Verhalten mithilfe von AND und OR in eine einzelne sql_always_having.

Wichtige Informationen

Es gibt einen ähnlichen Parameter für die SQL-WHERE-Klausel

Es gibt einen sehr ähnlichen Parameter wie sql_always_having mit dem Namen sql_always_where. Er funktioniert auf die gleiche Weise, allerdings werden Bedingungen auf die WHERE-Klausel und nicht auf die HAVING-Klausel angewendet.

Wenn Sie Filter möchten, die ein Nutzer ändern, aber nicht entfernen kann, sollten Sie always_filter verwenden

Wenn Sie möchten, dass Nutzer einen bestimmten Satz Filter verwenden, der Standardwert jedoch geändert werden kann, verwenden Sie stattdessen always_filter.

Wenn Sie benutzerdefinierte Filter verwenden möchten, die nicht geändert werden können, sollten Sie access_filter in Betracht ziehen.

Wenn Sie möchten, dass ein Filter für jeden Nutzer spezifisch ist und in keiner Weise geändert werden kann, können Sie access_filter verwenden.