Bonnes pratiques: ce qu'il faut faire et ne pas faire avec LookML

Ces bonnes pratiques reflètent les recommandations partagées par une équipe interfonctionnelle de Lookers expérimentés. Ces insights sont issus de nos années d'expérience auprès des clients Looker, de l'implémentation à la réussite à long terme. Ces pratiques sont conçues pour s'appliquer à la plupart des utilisateurs et des situations. Toutefois, comme toujours, utilisez votre bon sens lorsque vous mettez en œuvre l'une des recommandations partagées sur cette page.

Pour ce faire, utilisez LookML.

• À faire: définissez le paramètre relationship pour toutes les jointures.
  Vous vous assurerez ainsi que les métriques sont correctement agrégées dans Looker. Par défaut, Looker utilise une relation de jointure many_to_one pour toutes les jointures pour lesquelles aucune relation n'est définie. Pour en savoir plus sur la définition correcte du paramètre relationship, consultez la page des bonnes pratiques sur la configuration correcte du paramètre relationship.
• À faire: définissez une clé primaire dans chaque vue, y compris les tables dérivées.
  Toutes les vues, qu'elles soient dérivées ou issues directement de la base de données, doivent contenir une clé primaire. Cette clé primaire doit être une valeur unique pour permettre à Looker d'identifier de manière unique un enregistrement donné. Cette clé primaire peut être une seule colonne ou une concatenaison de colonnes. Il suffit qu'elle soit un identifiant unique pour la table ou la table dérivée.
• À faire: Nommez les dimensions, les mesures et les autres objets LookML en utilisant des lettres minuscules et des traits de soulignement pour les espaces.
  Le paramètre label permet de mettre en forme un champ de nom de manière supplémentaire. Il peut également être utilisé pour personnaliser l'apparence des noms de vues, des noms d'explorations et des noms de modèles. Par exemple, dans le code LookML suivant, le paramètre label est utilisé pour attribuer le libellé Nombre de clients à la mesure customer_count_distinct.

        measure: customer_count_distinct {
          label: "Number of Customers"
          type: count_distinct
          sql: ${customer.id} ;;
        }

• À faire: utilisez des groupes de données pour aligner la génération de tables dérivées persistantes (PDT) et explorer le mise en cache avec les processus ETL sous-jacents. Vous pouvez également utiliser des groupes de données pour déclencher l'envoi de tableaux de bord ou de présentations afin de vous assurer que les données envoyées aux destinataires sont à jour.

À ne pas faire avec LookML

• Ne pas: utiliser le paramètre from pour renommer des vues dans une exploration.
  Utilisez plutôt le paramètre view_label. Pour en savoir plus sur la différence entre from et view_label, consultez la page de documentation du paramètre from (pour les explorations). Le paramètre from doit être utilisé principalement dans les cas suivants :
  • Jointures polymorphes (jointure de la même table plusieurs fois)
  • Autojointures (jointure d'une table à elle-même)
  • Rétablir le champ d'application d'une vue étendue à son nom d'origine
• Ne pas: utiliser les mots "date " ou"heure " dans le nom d'un groupe de dimensions.
  Looker ajoute chaque période à la fin du nom du groupe de dimensions. Par conséquent, un groupe de dimensions nommé created_date génère des champs appelés, par exemple, created_date_date et created_date_month. Utilisez simplement created comme nom de groupe de dimensions, car les champs seront nommés, par exemple, created_date et created_month.
• Ne pas: utiliser des codes temporels formatés dans les jointures.
  Utilisez plutôt l'option Période brute pour effectuer une jointure sur des champs de date ou d'heure. Vous éviterez ainsi d'inclure le casting et la conversion de fuseau horaire dans les prédicats de jointure.