sql_on

Utilisation

explore: view_name_1 {
  join: view_name_2 {
    sql_on: ${view_name_1.id} = ${view_name_2.id} ;;
  }
}
Hiérarchie
explore
join
sql_on
Valeur par défaut
Aucun

Acceptation
Clause SQL ON

Règles spéciales
sql_on, sql_foreign_key et foreign_key ne peuvent pas être utilisés en même temps dans la même join.

Définition

sql_on établit une relation de jointure entre une vue et son exploration, en fonction d'une clause SQL ON que vous fournissez.

Pour LookML, l'ordre des conditions dans sql_on n'a pas d'importance. Ainsi, sql_on: ${order.user_id} = ${user.id} ;; et sql_on: ${user.id} = ${order.user_id} ;; sont équivalents. Vous pouvez placer les conditions dans n'importe quel ordre, sauf si l'ordre est pertinent pour le dialecte SQL de votre base de données.

Une vue peut être jointe directement à une exploration lorsque vous utilisez sql_on, ou elle peut être jointe via une deuxième vue déjà jointe à cette exploration.

Voici un exemple du premier cas, où une vue est jointe directement à l'exploration :

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

Le code SQL que Looker générerait à partir de ce code LookML est le suivant :

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

Dans le deuxième cas, une vue est jointe à une exploration via une vue intermédiaire déjà jointe à cette exploration. Voici un exemple :

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

Ici, customer ne peut pas être joint directement à order_items. Il doit plutôt être joint via order. Le code SQL que Looker générerait à partir de ce code LookML est le suivant :

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

Pour que cela fonctionne correctement, vous devez simplement utiliser les noms de vue corrects dans vos références de champ. Étant donné que customer doit être joint à un champ dans order, nous référençons ${order.customer_id}.

Dans certains modèles plus anciens, vous pouvez voir des champs référencés avec la syntaxe view_name.native_column_name. Bien que cela fonctionne toujours, l'utilisation de la syntaxe ${view_name.looker_dimension_name} présente un avantage important : vous pouvez éviter d'utiliser le paramètre required_joins. Ce concept est expliqué plus en détail dans la section Utiliser required_joins lorsque la syntaxe ${view_name.looker_dimension_name} ne peut pas être utilisée sur cette page.

Jointures conditionnelles

Il est également possible d'autoriser l'utilisation des entrées utilisateur dans sql_on. Bien que vous puissiez avoir plusieurs raisons de le faire, l'optimisation de la vitesse des requêtes sur les bases de données MPP (telles que Redshift) est un cas d'utilisation majeur, comme décrit dans le post de la communauté Conditions in Join Clauses.

Pour ajouter une entrée utilisateur à votre condition de jointure, vous devez d'abord créer un filtre pour cette entrée. Ces types de filtres sont décrits plus en détail sur la page Filtres basés sur des modèles. Voici leur forme de base :

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

Une fois que vous avez ajouté un filtre pour collecter l'entrée utilisateur, vous l'utilisez dans votre paramètre sql_on comme suit :

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

Exemple :

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

Cela signifie que customer.created_at est égal à la valeur de customer.creation_date_filter.

Utiliser les variables Liquid _in_query, _is_selected et _is_filtered

Les variables Liquid _in_query, _is_selected, et _is_filtered peuvent être utiles lorsqu'elles sont utilisées avec le paramètre sql_on. Elles vous permettent de modifier les relations de jointure en fonction des champs qu'un utilisateur a sélectionnés pour sa requête. Exemple :

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

Exemples

Joignez la vue nommée customer à l'exploration nommée order en faisant correspondre la dimension customer_id de order à la dimension id de customer :

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

Joignez la vue nommée customer à l'exploration nommée order_items via la vue appelée order. Faites correspondre la dimension customer_id de order à la dimension id de customer. Faites correspondre la dimension order_id de order_items à la dimension id de order. Cela serait spécifié comme suit :

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

Joignez les vues nommées order et inventory_items à l'exploration nommée order_items. Faites correspondre la dimension inventory_id de order_items à la dimension id de inventory_item. Faites correspondre la dimension order_id de order_items à la dimension id de order. Cela serait spécifié comme suit :

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

Bon à savoir

Utiliser required_joins lorsque la syntaxe ${view_name.looker_dimension_name} ne peut pas être utilisée

Lorsque vous référencez des champs dans sql_on à l'aide de la syntaxe ${view_name.looker_dimension_name}, vous n'avez pas à vous soucier de l'utilisation de required_joins.

Toutefois, certains modèles plus anciens utilisent encore la syntaxe view_name.native_column_name. Dans certains cas, vous ne pouvez pas utiliser la syntaxe ${view_name.looker_dimension_name}, par exemple lorsque vous souhaitez appliquer du code SQL personnalisé.

Dans ces situations, vous devrez peut-être utiliser required_joins. Pour en savoir plus, consultez la page de documentation sur le paramètre required_joins.