sql_on

Nutzung

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

Hierarchie Model File explore join sql_on

Standardwert Keine Akzeptiert Eine SQL-ON-Klausel Besondere Regeln sql_on, sql_foreign_key und foreign_key dürfen nicht gleichzeitig innerhalb derselben join verwendet werden.

Definition

Mit sql_on wird eine Join-Beziehung zwischen einer Ansicht und dem zugehörigen Explore auf Grundlage einer von Ihnen angegebenen SQL-ON-Klausel hergestellt.

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 beliebiger Reihenfolge angeben, es sei denn, die Reihenfolge ist für den SQL-Dialekt Ihrer Datenbank relevant.

Eine Ansicht kann mit sql_on direkt mit einem Explore verknüpft werden oder über eine zweite Ansicht, die bereits mit diesem Explore verknüpft ist.

Ein Beispiel für den ersten Fall, in dem eine Ansicht direkt mit dem Explore verknüpft wird, sieht so aus:

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

Der SQL-Code, den Looker aus diesem LookML-Code generieren würde, lautet:

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

Im zweiten Fall wird eine Ansicht über eine Zwischenansicht, die bereits mit dem Explore verknüpft ist, mit einem Explore verknüpft. 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 verbunden werden. Stattdessen muss sie mit order verknüpft werden. Der SQL-Code, den Looker aus diesem LookML-Code generieren würde, lautet:

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

Damit das funktioniert, müssen wir nur die richtigen Ansichtsnamen in unseren Feldreferenzen verwenden. Da customer mit einem Feld in order verknüpft werden muss, verweisen wir auf ${order.customer_id}.

Bei einigen älteren Modellen werden Felder möglicherweise mit der view_name.native_column_name-Syntax referenziert. Das funktioniert zwar weiterhin, aber die Verwendung der ${view_name.looker_dimension_name}-Syntax hat einen wichtigen Vorteil: Sie können den Parameter required_joins vermeiden. Dieses Konzept wird auf dieser Seite im Abschnitt required_joins verwenden, wenn die ${view_name.looker_dimension_name}-Syntax nicht verwendet werden kann ausführlicher erläutert.

Bedingte Joins

Es ist auch möglich, die Verwendung von Nutzereingaben in sql_on zuzulassen. Dafür kann es verschiedene Gründe geben. Ein wichtiger Anwendungsfall ist jedoch die Optimierung der Abfragegeschwindigkeit in MPP-Datenbanken (wie Redshift), wie im Community-Beitrag Bedingungen in Join-Klauseln beschrieben.

Wenn Sie der Join-Bedingung Nutzereingaben hinzufügen möchten, müssen Sie zuerst einen Filter für die Eingaben erstellen. Diese Filtertypen werden auf der Seite Vorlagenfilter ausführlicher beschrieben. Die Grundform ist:

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 so im Parameter sql_on:

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

Das würde so interpretiert werden: Setze customer.created_at auf den Wert von customer.creation_date_filter.

Liquid-Variablen _in_query, _is_selected und _is_filtered verwenden

Die Liquid-Variablen _in_query, _is_selected und _is_filtered können in Verbindung mit dem Parameter sql_on nützlich sein. Damit können Sie 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} =
      {% if dates.reporting_date._in_query %}
        ${dates.date_string}
      {% elsif dates.reporting_week._in_query %}
        ${dates.week_string}
      {% else %}
        ${dates.month_string}
      {% endif %} ;;
  }
}

Beispiele

Verknüpfen Sie die Ansicht mit dem Namen customer mit dem Explore 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} ;;
  }
}

Verknüpfen Sie die Ansicht mit dem Namen customer über die Ansicht mit dem Namen order mit dem Explore mit dem Namen order_items. Ordnen Sie die Dimension customer_id aus order der Dimension id aus customer zu. Ordnen Sie die Dimension order_id aus order_items der Dimension id aus order zu. Das würde so angegeben:

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

Führen Sie die Ansichten mit den Namen order und inventory_items mit dem Explore mit dem Namen order_items zusammen. Ordnen Sie die Dimension inventory_id aus order_items der Dimension id aus inventory_item zu. Ordnen Sie die Dimension order_id aus order_items der Dimension id aus order zu. Das würde so 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 Punkte

required_joins verwenden, wenn die ${view_name.looker_dimension_name}-Syntax nicht verwendet werden kann

Wenn Sie mit der ${view_name.looker_dimension_name}-Syntax auf Felder in sql_on verweisen, müssen Sie sich nicht um die Verwendung von required_joins kümmern.

Bei einigen älteren Modellen wird jedoch noch die view_name.native_column_name-Syntax verwendet. Es gibt auch einige Fälle, in denen Sie die ${view_name.looker_dimension_name}-Syntax nicht verwenden können, z. B. wenn Sie benutzerdefiniertes SQL anwenden möchten.

In diesen Fällen müssen Sie möglicherweise required_joins verwenden. Sie werden auf der Dokumentationsseite für required_joins-Parameter ausführlicher beschrieben.