Best practice: cosa fare e cosa non fare con LookML

Queste best practice riflettono i consigli condivisi da un team interfunzionale di esperti Looker. Questi approfondimenti nascono da anni di esperienza nella collaborazione con i clienti di Looker, dall'implementazione al successo a lungo termine. Queste pratiche sono scritte per funzionare per la maggior parte degli utenti e delle situazioni, ma, come sempre, usa il tuo buon senso quando implementi i consigli condivisi in questa pagina.

Do di LookML

• Azione: definisci il parametro relationship per tutte le unioni.
  In questo modo, le metriche verranno aggregate correttamente in Looker. Per impostazione predefinita, Looker utilizza una relazione di join many_to_one per tutti i join per cui non è definita una relazione. Per ulteriori informazioni sulla definizione corretta del parametro relationship, consulta la pagina Best practice su come utilizzare correttamente il parametro relationship.
• Azione: definisci una chiave primaria in ogni vista, incluse le tabelle derivate.
  Tutte le viste, che siano derivate o provenienti direttamente dal database, devono contenere una chiave primaria. Questa chiave primaria deve essere un valore univoco per consentire a Looker di identificare in modo univoco qualsiasi record. Questa chiave primaria può essere una singola colonna o una concatenazione di colonne; deve semplicemente essere un identificatore univoco per la tabella o la tabella derivata.
• Azione: assegna un nome a dimensioni, misure e altri oggetti LookML, utilizzando solo lettere minuscole e trattini bassi per gli spazi.
  Il parametro label può essere utilizzato per la formattazione aggiuntiva di un campo del nome e anche per personalizzare l'aspetto dei nomi delle visualizzazioni, dei nomi delle esplorazioni e dei nomi dei modelli. Ad esempio, nel seguente codice LookML, il parametro label viene utilizzato per assegnare l'etichetta Numero di clienti alla misura customer_count_distinct.

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

• Azione: utilizza i gruppi di dati per allineare la generazione di tabelle derivate permanenti (PDT) ed esplorare la memorizzazione nella cache con i processi ETL sottostanti. I gruppi di dati possono essere utilizzati anche per attivare le pubblicazioni di dashboard o Look per garantire che ai destinatari vengano inviati dati aggiornati.

Cosa non fare in LookML

• Non: utilizza il parametro from per rinominare le visualizzazioni all'interno di un'esplorazione.
  Utilizza invece il parametro view_label. Per saperne di più sulla differenza tra from e view_label, consulta la pagina della documentazione relativa al parametro from (per le esplorazioni). Il parametro from deve essere utilizzato principalmente nelle seguenti situazioni:
  • Join polimorfici (unione della stessa tabella più volte)
  • Self-join (unione di una tabella con se stessa)
  • Reimpostazione dell'ambito di una visualizzazione estesa al nome originale
• Non: utilizzare la parola "data" o "ora" nel nome di un gruppo di dimensioni.
  Looker aggiunge ogni periodo di tempo alla fine del nome del gruppo di dimensioni. Ciò significa che un gruppo di dimensioni denominato created_date genera campi denominati created_date_date, created_date_month e così via. Utilizza semplicemente created come nome del gruppo di dimensioni, perché in questo modo i campi avranno nomi come created_date, created_month e così via.
• Non: utilizzare timestamp formattati all'interno delle unioni.
  Utilizza invece l'opzione intervallo di tempo non elaborato per eseguire l'unione in qualsiasi campo di data o ora. In questo modo, eviterai l'inclusione di conversioni di tipo di dati e fuso orario nei predicati di join.