Nutzung
join: view_name_2 {
sql_on: ${view_name_1.id} = ${view_name_2.id} ;;
}
}
Hierarchie
sql_on |
Standardwert
KeineAkzeptiert
Eine SQL-ON -KlauselSonderregeln
sql_on , sql_foreign_key und foreign_key dürfen nicht gleichzeitig innerhalb derselben join verwendet werden
|
Definition
sql_on
stellt anhand einer von Ihnen bereitgestellten SQL-ON
-Klausel eine Join-Beziehung zwischen einer Ansicht und der Funktion „Erkunden“ her.
Bei LookML spielt die Reihenfolge der Bedingungen in sql_on
keine Rolle. sql_on: ${order.user_id} = ${user.id} ;;
und sql_on: ${user.id} = ${order.user_id} ;;
sind also gleichwertig. Sie können die Bedingungen in eine beliebige Reihenfolge bringen, es sei denn, die Reihenfolge ist für den SQL-Dialekt Ihrer Datenbank relevant.
Eine Ansicht kann direkt mit einem explorativen Analysetool verknüpft werden, wenn sql_on
verwendet wird, oder über eine zweite Ansicht, die bereits mit diesem explorativen Analysetool verknüpft ist.
Hier ein Beispiel für den ersten Fall, bei dem eine Ansicht direkt mit dem Tab „Entdecken“ verknüpft wurde:
explore: order {
join: customer {
sql_on: ${order.customer_id} = ${customer.id} ;;
}
}
SQL generiert Looker aus diesem LookML:
SELECT ...
FROM order
LEFT JOIN customer
ON order.customer_id = customer.id
Im zweiten Fall wird eine Ansicht über eine Zwischenansicht, die bereits mit dieser Funktion verknüpft ist, mit einer anderen Datenansicht verknüpft. Hier ein Beispiel:
explore: order_items {
join: order {
sql_on: ${order_items.order_id} = ${order.id} ;;
}
join: customer {
sql_on: ${order.customer_id} = ${customer.id} ;;
}
}
Hier kann customer
nicht direkt mit order_items
verknüpft werden. Sie muss stattdessen über order
verknüpft werden. SQL generiert Looker aus diesem LookML:
SELECT ...
FROM order_items
LEFT JOIN order
ON order_items.order_id = order.id
LEFT JOIN customer
ON order.customer_id = customer.id
Damit dies richtig funktioniert, müssen Sie in unseren Feldreferenzen nur die richtigen Ansichtsnamen verwenden. Da customer
mit einem Feld in order
verknüpft werden muss, verweisen wir auf ${order.customer_id}
.
In einigen älteren Modellen werden möglicherweise Felder angezeigt, auf die die Syntax
view_name.native_column_name
verweist. Dies funktioniert zwar weiterhin, die Verwendung der${view_name.looker_dimension_name}
-Syntax hat jedoch einen wichtigen Vorteil: Du kannst den Parameterrequired_joins
vermeiden. Dieses Konzept wird im Abschnittrequired_joins
verwenden, wenn die${view_name.looker_dimension_name}
-Syntax nicht verwendet werden kann auf dieser Seite ausführlicher erläutert.
Bedingte Joins
Es ist auch möglich, die Verwendung der Nutzereingabe in sql_on
zuzulassen. Auch wenn dies verschiedene Gründe haben kann, ist die Optimierung der Abfragegeschwindigkeit in MPP-Datenbanken wie Redshift ein wichtiger Anwendungsfall. Weitere Informationen hierzu finden Sie in diesem Community-Thema.
Wenn Sie Ihrer Join-Bedingung Nutzereingaben hinzufügen möchten, müssen Sie zuerst einen Filter für deren Eingabe erstellen. Diese Filtertypen werden auf der Seite Vorlagenvorlagen genauer beschrieben. Ihre grundlegende Form lautet:
view: view_name {
filter: filter_name {
type: number | datetime | date | string
}
}
Nachdem Sie einen Filter zum Erfassen der Nutzereingabe hinzugefügt haben, verwenden Sie ihn im sql_on
-Parameter:
{% condition view_name.filter_name %} view_name.dimension_name {% endcondition %}
Beispiel:
explore: order {
join: customer {
sql_on:
${order.customer_id} = ${customer.id} AND
{% condition customer.creation_date_filter %} customer.created_at {% endcondition %} ;;
}
}
Dies würde so ausgelegt: „customer.created_at
“ ist gleich dem Wert von customer.creation_date_filter
.
_in_query
, _is_selected
und _is_filtered
Liquid-Variablen verwenden
Die Flüssigkeitsvariablen _in_query
, _is_selected
und _is_filtered
können in Kombination mit dem Parameter sql_on
hilfreich sein. Sie können Join-Beziehungen basierend auf den Feldern ändern, die ein Nutzer für seine Abfrage ausgewählt hat. Beispiel:
explore: dates {
join: dynamic_order_counts {
sql_on:
${dynamic_order_counts.period} =
{% dynamic if dates.reporting_date._in_query %}
${dates.date_string}
{% elsif dates.reporting_week._in_query %}
${dates.week_string}
{% dynamic else %}
${dates.month_string}
{% dynamic endif %} ;;
}
}
Beispiele
Verknüpfen Sie die Ansicht „customer
“ mit dem Bericht „Erkunden“ mit dem Namen „order
“, indem Sie die Dimension „customer_id
“ aus „order
“ mit der Dimension „id
“ aus customer
abgleichen:
explore: order {
join: customer {
sql_on: ${order.customer_id} = ${customer.id} ;;
}
}
Verbinden Sie die Ansicht namens customer
mit der Ansicht order_items
über die Ansicht order
. Gleichen Sie die Dimension customer_id
aus order
mit der Dimension id
aus customer
ab. Gleichen Sie die Dimension order_id
aus order_items
mit der Dimension id
aus order
ab. Diese wird folgendermaßen angegeben:
explore: order_items {
join: order {
sql_on: ${order_items.order_id} = ${order.id} ;;
}
join: customer {
sql_on: ${order.customer_id} = ${customer.id} ;;
}
}
Verbinden Sie die Ansichten order
und inventory_items
mit dem Tab „Erkunden“ mit dem Namen order_items
. Gleichen Sie die Dimension inventory_id
aus order_items
mit der Dimension id
aus inventory_item
ab. Gleichen Sie die Dimension order_id
aus order_items
mit der Dimension id
aus order
ab. Diese wird folgendermaßen angegeben:
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} ;;
}
}
Wichtige Informationen
required_joins
verwenden, wenn die ${view_name.looker_dimension_name}
-Syntax nicht verwendet werden kann
Wenn Sie in sql_on
Felder mit der Syntax ${view_name.looker_dimension_name}
verweisen, müssen Sie sich nicht um die Verwendung von required_joins
kümmern.
Einige ältere Modelle verwenden jedoch weiterhin die Syntax view_name.native_column_name
. Es gibt auch Fälle, in denen Sie die Syntax ${view_name.looker_dimension_name}
nicht verwenden können, z. B. wenn Sie benutzerdefinierten SQL-Code anwenden möchten.
In diesen Fällen müssen Sie möglicherweise required_joins
verwenden. Sie werden auf der Dokumentationsseite zum Parameter required_joins
ausführlicher beschrieben.