Praktik terbaik: Hal yang harus dilakukan dan tidak boleh dilakukan dengan LookML
Tetap teratur dengan koleksi
Simpan dan kategorikan konten berdasarkan preferensi Anda.
Praktik terbaik ini mencerminkan rekomendasi yang dibagikan oleh tim lintas fungsional yang terdiri dari Looker berpengalaman. Insight ini berasal dari pengalaman bertahun-tahun bekerja dengan pelanggan Looker, mulai dari penerapan hingga kesuksesan jangka panjang. Praktik ini ditulis agar dapat digunakan oleh sebagian besar pengguna dan situasi, tetapi — seperti biasa — gunakan pertimbangan terbaik Anda saat menerapkan rekomendasi apa pun yang dibagikan di halaman ini.
Melakukannya dengan LookML
Lakukan: Tentukan parameter relationship untuk semua join.
Tindakan ini akan memastikan bahwa metrik digabungkan dengan benar dalam Looker. Secara default, Looker akan menggunakan hubungan join many_to_one untuk join apa pun yang hubungannya tidak ditentukan. Untuk informasi tambahan tentang cara menentukan parameter relationship dengan benar, lihat halaman Praktik Terbaik tentang cara mendapatkan parameter relationship yang tepat.
Lakukan: Tentukan kunci utama dalam setiap tampilan, termasuk tabel turunan.
Semua tampilan, baik yang berasal dari atau langsung dari database, harus berisi kunci utama. Kunci utama ini harus berupa nilai unik agar Looker dapat mengidentifikasi data tertentu secara unik. Kunci utama ini dapat berupa satu kolom atau gabungan kolom — kunci utama ini hanya perlu berupa ID unik untuk tabel atau tabel turunan.
Lakukan: Beri nama dimensi, ukuran, dan objek LookML lainnya, menggunakan semua huruf kecil dan garis bawah untuk spasi.
Parameter label dapat digunakan untuk pemformatan tambahan kolom nama, dan juga dapat digunakan untuk menyesuaikan tampilan nama tampilan, nama Jelajahi, dan nama model. Misalnya, dalam LookML berikut, parameter label digunakan untuk menetapkan label Jumlah Pelanggan ke ukuran customer_count_distinct.
Lakukan: Gunakan datagroup untuk menyelaraskan pembuatan tabel turunan persisten (PDT) dan Menjelajahi penyimpanan dalam cache dengan proses ETL yang mendasarinya. Grup data juga dapat digunakan untuk memicu pengiriman dasbor atau Tampilan untuk memastikan data terbaru dikirim kepada penerima.
Jangan lakukan ini dengan LookML
Jangan: Gunakan parameter from untuk mengganti nama tampilan dalam Jelajah.
Sebagai gantinya, gunakan parameter view_label. Untuk mengetahui perbedaan antara from dan view_label lebih lanjut, lihat halaman dokumentasi parameter from (untuk Jelajah). Parameter from terutama harus digunakan dalam situasi berikut:
Join polimorfik (menggabungkan tabel yang sama beberapa kali)
Self-join (menggabungkan tabel dengan dirinya sendiri)
Menentukan cakupan ulang tampilan yang diperluas kembali ke nama tampilan aslinya
Jangan: Gunakan kata "tanggal" atau "waktu" dalam nama grup dimensi.
Looker menambahkan setiap jangka waktu ke akhir nama grup dimensi, yang berarti bahwa grup dimensi yang bernama created_date akan menghasilkan kolom yang disebut, misalnya, created_date_date dan created_date_month. Cukup gunakan created sebagai nama grup dimensi, karena hal ini akan menghasilkan kolom yang diberi nama, misalnya, created_date dan created_month.
Jangan: Gunakan stempel waktu berformat dalam join.
Sebagai gantinya, gunakan opsi jangka waktu mentah untuk menggabungkan kolom tanggal atau waktu. Hal ini akan menghindari penyertaan konversi zona waktu dan transmisi dalam predikat join.
[[["Mudah dipahami","easyToUnderstand","thumb-up"],["Memecahkan masalah saya","solvedMyProblem","thumb-up"],["Lainnya","otherUp","thumb-up"]],[["Sulit dipahami","hardToUnderstand","thumb-down"],["Informasi atau kode contoh salah","incorrectInformationOrSampleCode","thumb-down"],["Informasi/contoh yang saya butuhkan tidak ada","missingTheInformationSamplesINeed","thumb-down"],["Masalah terjemahan","translationIssue","thumb-down"],["Lainnya","otherDown","thumb-down"]],["Terakhir diperbarui pada 2025-07-31 UTC."],[],[],null,["# Best practice: What to do and what not to do with LookML\n\nThese best practices reflect recommendations that were shared by a cross-functional team of seasoned Lookers. These insights come from years of experience working with Looker customers from implementation to long-term success. The practices are written to work for most users and situations, but --- as always --- use your best judgment when implementing any of the recommendations that are shared on this page.\n\nDo this with LookML\n-------------------\n\n- **Do** : Define the [`relationship`](/looker/docs/reference/param-explore-join-relationship) parameter for all joins.\n\n \u003cbr /\u003e\n\n This will ensure that metrics aggregate properly within Looker. By default, Looker will use a `many_to_one` join relationship for any joins in which a relationship is not defined. For additional information on defining the `relationship` parameter correctly, see the Best Practices page on [getting the `relationship` parameter right](/looker/docs/best-practices/how-to-use-the-relationship-parameter-correctly).\n- **Do** : Define a [primary key](/looker/docs/reference/param-field-primary-key) within each and every view, including derived tables.\n\n \u003cbr /\u003e\n\n All views, whether they are derived or coming directly from the database, should contain a primary key. This primary key should be a *unique value* to enable Looker to uniquely identify any given record. This primary key can be a single column or a concatenation of columns --- it simply needs to be a unique identifier for the table or derived table.\n- **Do** : Name [dimensions](/looker/docs/reference/param-field-dimension), [measures](/looker/docs/reference/param-field-measure), and other LookML objects, using all lowercase letters and underscores for spaces.\n\n \u003cbr /\u003e\n\n The [`label` parameter](/looker/docs/reference/param-field-label) can be used for additional formatting of a name field, and can also be used to customize the appearance of [view names](/looker/docs/reference/param-view-label), [Explore names](/looker/docs/reference/param-explore-label), and [model names](/looker/docs/reference/param-model-label). For example, in the following LookML, the `label` parameter is used to assign the label **Number of Customers** to the `customer_count_distinct` measure. \n\n ```\n measure: customer_count_distinct {\n label: \"Number of Customers\"\n type: count_distinct\n sql: ${customer.id} ;;\n }\n ```\n- **Do** : Use [datagroups](/looker/docs/reference/param-model-datagroup) to align generation of [persistent derived tables (PDTs)](/looker/docs/caching-and-datagroups) and Explore caching with underlying ETL processes. Datagroups can also be used to trigger deliveries of [dashboards](/looker/docs/scheduling-and-sending-dashboards#schedules_triggered_by_datagroup_updates) or [Looks](/looker/docs/delivering-looks-explores#specifying_the_datagroup_trigger) to ensure that up-to-date data is sent to recipients.\n\nDon't do this with LookML\n-------------------------\n\n- **Don't** : Use the `from` parameter for renaming views within an Explore.\n\n \u003cbr /\u003e\n\n \u003cbr /\u003e\n\n Use the [`view_label`](/looker/docs/reference/param-explore-view-label) parameter instead. For more on the difference between `from` and `view_label`, check out the [`from` (for Explores)](/looker/docs/reference/param-explore-from) parameter documentation page. The `from` parameter should primarily be used in the following situations:\n - Polymorphic joins (joining the same table multiple times)\n - [Self-joins](/looker/docs/working-with-joins#joining_a_view_more_than_once) (joining a table to itself)\n - Re-scoping an extended view back to its original view name\n- **Don't** : Use the word \"date\" or \"time\" in a [dimension group](/looker/docs/reference/param-field-dimension-group) name.\n\n \u003cbr /\u003e\n\n \u003cbr /\u003e\n\n Looker appends each timeframe to the end of the dimension group name, which means that a dimension group that is named `created_date` results in fields called, for example, `created_date_date` and `created_date_month`. Simply use `created` as the dimension group name, because this results in fields that are named, for example, `created_date` and `created_month`.\n- **Don't** : Use formatted timestamps within joins.\n\n \u003cbr /\u003e\n\n \u003cbr /\u003e\n\n Instead, use the [raw timeframe](/looker/docs/reference/param-field-dimension-group#timeframes) option for joining on any date or time fields. This will avoid the inclusion of casting and timezone conversion in join predicates."]]
