sql_on

Utilisation

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

Hiérarchie Fichier de modèle 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 le 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. sql_on: ${order.user_id} = ${user.id} ;; et sql_on: ${user.id} = ${order.user_id} ;; sont donc équivalents. Vous pouvez placer les conditions dans l'ordre de votre choix, 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 par le biais d'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 second cas, une vue est jointe à une exploration par le biais d'une vue intermédiaire déjà jointe à cette exploration. Par 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. Vous devez plutôt le rejoindre 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 vues appropriés dans vos références de champs. Étant donné que customer doit être joint à un champ dans order, nous faisons référence à ${order.customer_id}.

Dans certains anciens modèles, il est possible que les champs soient référencés avec la syntaxe view_name.native_column_name. Bien que cette méthode 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 saisies 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 (comme Redshift) est un cas d'utilisation majeur, comme décrit dans l'article de la communauté Conditions dans les clauses JOIN.

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 : définissez customer.created_at sur 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. Ils 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 avec la dimension id de customer. Faites correspondre la dimension order_id de order_items avec 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 avec la dimension id de inventory_item. Faites correspondre la dimension order_id de order_items avec 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 anciens modèles 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 un code SQL personnalisé.

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