Skip to Content

20 Years of SQL Advice in 11 Minutes

Halo, saya di sini. Sejak tahun 2004, saya sudah berkecimpung di dunia SQL, mulai dari proyek sampingan, peran profesional di berbagai perusahaan, hingga mengelola channel ini. Selama itu, saya sudah membuat banyak kesalahan, tapi saya juga menemukan banyak hal yang benar-benar efektif.

Banyak orang bisa menulis SQL, tapi hanya sedikit yang bisa menulis SQL yang efisien, mudah dibaca, dan aman.

Saya di sini bukan untuk mengajari Anda sintaks dasar. Saya di sini untuk mengubah cara pandang Anda terhadap SQL. Ini bukan sekadar alat untuk mengambil data; ini adalah sebuah keahlian, sebuah craftsmanship.

Berikut adalah materi komprehensif yang saya susun berdasarkan 20 tips utama saya, lengkap dengan sudut pandang yang jarang dilihat orang dan langkah-langkah yang bisa langsung Anda praktikkan.

🚀 Menguasai SQL: Dari Penulis Kode Menjadi Arsitek Data

Materi ini saya bagi menjadi empat bagian utama yang mencerminkan evolusi seorang profesional data:

  1. Fondasi (Code Craftsmanship): Menulis kode yang bersih dan bisa dipahami manusia.
  2. Struktur (The Architect's Mindset): Mendesain query kompleks dan struktur data yang logis.
  3. Efisiensi (The Professional's Workflow): Bekerja lebih cepat dan lebih cerdas.
  4. Integritas (The Guardian's Duty): Melindungi aset paling berharga: Data.

1. Fondasi: Menulis Kode yang Bersih (Code Craftsmanship)

Ini adalah tentang keterbacaan. Kode Anda akan lebih sering dibaca daripada ditulis, baik oleh Anda di masa depan maupun oleh rekan tim Anda.

Konsep 1: Alias adalah Kontrak (Tips 1 & 2)

  • Column Alias (AS): SELECT COUNT(id) AS jumlah_transaksi.
  • Table Alias: FROM products p JOIN orders o ON p.id = o.product_id.

Insight yang Sering Terlewat:

Orang mengira alias hanya untuk menyingkat. Itu salah. Alias adalah kontrak.

  • Column Alias adalah kontrak antara query Anda dan konsumen data (aplikasi, reporting tool seperti PowerBI, atau analis). Jika Anda tidak memberinya nama yang jelas (seperti jumlah_transaksi), database akan memberinya nama generik (seperti (No column name) atau count), yang akan merusak aplikasi atau dashboard.
  • Table Alias adalah kontrak antara query Anda dan otak Anda. Saat Anda melakukan JOIN 5 tabel, otak Anda tidak bisa mengingat product_categories, product_stock_levels, dst. Tapi otak Anda bisa dengan mudah memproses pc dan psl. Ini bukan soal menghemat ketikan; ini soal menghemat beban kognitif.

👉 Apa yang bisa kamu lakukan sekarang:

Buka query terpanjang yang Anda miliki. Jika ada join, wajibkan diri Anda menggunakan table alias yang singkat dan logis. Jika ada fungsi (SUM, AVG, COUNT), wajibkan menggunakan column alias yang deskriptif.

Konsep 2: Formatting adalah Struktur Logis (Tip 3)

Apakah SELECT harus huruf besar atau kecil? Apakah JOIN harus di baris baru?

Insight yang Sering Terlewat:

Debat soal style (huruf besar vs kecil) itu membuang waktu. Yang penting bukan style-nya, tapi konsistensi.

Formatting bukan soal "keindahan". Formatting adalah cara Anda mengungkapkan struktur logis dari query Anda. Query yang diformat dengan baik akan memisahkan dengan jelas blok SELECT (apa yang Anda ambil), blok FROM/JOIN (dari mana Anda ambil), dan blok WHERE/GROUP BY (bagaimana Anda memfilternya).

Jika Anda bekerja dalam tim, ego Anda harus kalah. Ikuti standar tim, bahkan jika Anda tidak 100% setuju. Konsistensi tim jauh lebih berharga daripada preferensi pribadi Anda.

👉 Apa yang bisa kamu lakukan sekarang:

Cari fitur "Format Query" di SQL editor Anda (seringnya shortcut seperti Ctrl+K, Ctrl+F atau sejenisnya). Gunakan fitur itu setiap kali Anda selesai menulis atau mengedit query. Jangan biarkan ada query yang Anda commit tanpa diformat.

2. Struktur: Pola Pikir Seorang Arsitek (The Architect's Mindset)

Ini adalah tentang cara Anda merancang query yang kompleks dan database yang logis agar tidak runtuh saat datanya bertambah besar.

Konsep 3: CTE adalah 'Storytelling' untuk Data (Tip 5)

Common Table Expression (CTE) adalah klausa WITH ... AS (...).

Insight yang Sering Terlewat:

Banyak orang terjebak dalam "neraka subquery". Mereka menulis query di dalam query di dalam query (SELECT ... FROM (SELECT ... FROM (SELECT ...))). Ini adalah mimpi buruk untuk di-debug.

CTE adalah cara Anda bercerita melalui query.

WITH

pengguna_aktif AS ( ... ),

transaksi_mereka AS ( ... ),

total_per_regional AS ( ... )

SELECT * FROM total_per_regional;

Ini mengubah query monolitik yang rumit menjadi modul-modul logis yang bisa dibaca seperti prosa. Anda mendefinisikan "bab" satu per satu, lalu menggabungkannya di akhir. Ini juga sangat membantu untuk reusability (logika yang sama dipakai berkali-kali dalam satu query).

👉 Apa yang bisa kamu lakukan sekarang:

Ambil query Anda yang paling rumit yang menggunakan nested subquery. Coba tulis ulang dari awal menggunakan CTE. Anda akan kaget betapa jauh lebih bersih hasilnya.

Konsep 4: Window Function adalah 'Superpower' Anda (Tip 6)

ROW_NUMBER() OVER (PARTITION BY ... ORDER BY ...)

SUM(total) OVER (PARTITION BY ...)

Insight yang Sering Terlewat:

Dulu, jika Anda ingin melihat detail penjualan dan total penjualan per kategori dalam satu tabel, Anda harus melakukan hal-hal rumit (misalnya, query dua kali lalu menggabungkannya di aplikasi).

Window Function membiarkan Anda melakukan agregasi (SUM, COUNT, AVG) TANPA harus menggunakan GROUP BY. GROUP BY akan "meruntuhkan" (meng-kolaps) baris Anda menjadi satu. Window Function menjaga semua baris detail tetap ada, sambil "menempelkan" hasil agregasi di sampingnya.

Ini adalah pembeda besar antara analis data junior dan senior.

👉 Apa yang bisa kamu lakukan sekarang:

Coba selesaikan tantangan ini: "Tampilkan daftar SEMUA karyawan, gajinya, DAN gaji rata-rata di departemennya masing-masing, dalam satu query." Ini adalah kasus klasik untuk AVG(...) OVER (PARTITION BY department_id).

Konsep 5: Normalisasi adalah tentang 'Satu Sumber Kebenaran' (Tips 19, 11, 17)

  • Tip 19 (Store Data Once): Jangan simpan data yang sama di banyak tempat.
  • Tip 11 (Define Logic Once): Jangan ulangi logika query di banyak tempat.
  • Tip 17 (Surrogate Keys): Jangan gunakan business key sebagai primary key.

Insight yang Sering Terlewat:

Ketiga tips ini adalah tentang satu filosofi inti: Single Source of Truth (Satu Sumber Kebenaran).

  • Tip 19 (Data): Jika alamat pelanggan ada di tabel customers DAN tabel orders, alamat mana yang benar jika dia pindah? Ini adalah bencana data. Alamat harus ada di satu tempat. Inilah inti dari Normalisasi.
  • Tip 17 (Identifier): Orang suka menggunakan "data bisnis" (No KTP, No Telepon, SKU Produk) sebagai Primary Key (PK). Ini kesalahan fatal. Apa yang terjadi jika No KTP-nya salah input? Anda tidak bisa mengubah PK dengan mudah. Apa yang terjadi jika SKU produk berubah karena rebranding? PK harus bodoh dan abadi. Ia tidak boleh punya arti bisnis. Gunakan Surrogate Key (kunci buatan), seperti INT AUTO_INCREMENT atau UUID.
  • Tip 11 (Logic): Jika Anda punya 5 dashboard berbeda yang semuanya perlu menghitung "Pendapatan Bersih", jangan copy-paste logika CASE WHEN... yang rumit itu ke 5 query berbeda. Simpan logika itu di satu tempat, misalnya VIEW atau function. Jadi, saat definisinya berubah, Anda hanya perlu mengubahnya di satu tempat.

👉 Apa yang bisa kamu lakukan sekarang:

Saat Anda mendesain tabel baru, selalu tambahkan kolom id INT atau id UUID sebagai Primary Key. Tanyakan pada diri Anda: "Jika data ini berubah, di mana lagi saya harus mengubahnya?" Jika jawabannya "di tabel lain", desain Anda salah.

3. Efisiensi: Alur Kerja Seorang Profesional (The Professional's Workflow)

Ini adalah tentang cara Anda bekerja. Seorang profesional tidak membuang waktu untuk hal-hal yang bisa diotomatisasi.

Konsep 6: Editor Anda adalah Kokpit, Bukan Mesin Tik (Tips 8, 16)

Query Anda mungkin lambat, tapi Anda tidak seharusnya lambat.

Insight yang Sering Terlewat:

Editor SQL Anda (DBeaver, DataGrip, SSMS, dll.) mungkin memiliki fitur Git, perbandingan skema, pembuatan mock data, dan puluhan fitur lain yang tidak pernah Anda sentuh.

Tapi yang paling fundamental adalah Keyboard Shortcuts (Tip 8). Anda akan menjalankan query ribuan kali dalam karier Anda. Jika Anda masih menggunakan mouse untuk klik tombol "Run", Anda membuang waktu. Ctrl+Enter atau F5 adalah teman baik Anda. Pelajari shortcut untuk memformat, memberi komentar, dan menduplikasi baris. Ini adalah investasi milidetik yang akan terbayar ribuan jam.

👉 Apa yang bisa kamu lakukan sekarang:

Hari ini, cari daftar keyboard shortcut untuk editor SQL Anda. Tempel di dinding Anda. Paksa diri Anda menggunakan 3 shortcut baru minggu ini (misal: "Run Query", "Format Code", "Comment Line").

Konsep 7: Version Control adalah Mesin Waktu Anda (Tip 4)

Simpan skrip .sql Anda di Git (GitHub, GitLab, dll.).

Insight yang Sering Terlewat:

Ini adalah pembeda terbesar antara "dunia database" dan "dunia software development". Banyak orang database tidak menggunakan Version Control. Mereka beralasan, "datanya sudah di-backup."

Ini bukan tentang backup data. Ini tentang histori perubahan skrip Anda.

  • Kenapa query ini diubah 6 bulan lalu?
  • Siapa yang menambahkan logika ini?
  • Bagaimana mengembalikan stored procedure ke versi minggu lalu saat semuanya masih berjalan baik?

Tanpa Version Control, jawaban Anda adalah: "Saya tidak tahu."

👉 Apa yang bisa kamu lakukan sekarang:

Buat repository Git baru (bisa private gratis). Mulai hari ini, simpan semua skrip penting Anda di sana. git commit -m "Menambahkan query laporan penjualan bulanan" jauh lebih baik daripada laporan_final_v2_fix_banget.sql.

Konsep 8: Execution Plan adalah Peta Harta Karun (Tip 10)

Ini adalah langkah pertama untuk performance tuning.

Insight yang Sering Terlewat:

Menulis SQL tanpa pernah melihat Execution Plan adalah seperti mengemudi di kota asing tanpa GPS. Anda mungkin sampai, tapi Anda tidak tahu kenapa Anda terjebak macet.

Execution Plan adalah cara database memberi tahu Anda strategi yang akan ia gunakan untuk menjalankan query Anda. Anda tidak perlu hafal semua istilahnya. Cukup cari satu kata: "Table Scan" atau "Full Scan".

Jika Anda melihat "Table Scan" pada tabel berisi 10 juta baris, itu artinya database sedang membaca 10 juta baris itu satu per satu hanya untuk menemukan 5 baris yang Anda cari. Ini adalah tanda paling jelas bahwa Anda mungkin melewatkan sebuah INDEX.

👉 Apa yang bisa kamu lakukan sekarang:

Ambil query Anda yang paling lambat. Cari tombol "Execution Plan" atau "Query Plan" di editor Anda. Jalankan. Cari kata "Scan". Jika Anda menemukannya di tabel besar, Anda baru saja menemukan kandidat pertama untuk perbaikan.

4. Integritas: Tugas Seorang Penjaga (The Guardian's Duty)

Ini adalah bagian terpenting. Anda bisa memperbaiki query yang lambat. Jauh lebih sulit memperbaiki data yang rusak atau hilang.

Konsep 9: SELECT * dan Join yang Ceroboh (Tips 7, 9, 13, 15)

  • Tip 13 (Avoid SELECT *): Jangan gunakan SELECT * di kode produksi.
  • Tip 9 (Don't use WHERE for Joins): Gunakan sintaks JOIN ... ON.
  • Tip 7 (Avoid NATURAL JOIN): Terlalu implisit dan berbahaya.
  • Tip 15 (Don't Fear Joins): Database didesain untuk JOIN.

Insight yang Sering Terlewat:

  • SELECT * itu malas dan berbahaya. Mengapa?
    1. Performa: Anda menarik data (misal: kolom BLOB atau TEXT besar) yang tidak Anda perlukan.
    2. Kerapuhan: Jika seseorang menambahkan kolom baru ke tabel, urutan kolom di aplikasi Anda bisa rusak.
    3. Keterbacaan: Anda (atau orang lain) tidak tahu kolom apa yang sebenarnya dibutuhkan oleh query ini. Selalu tulis kolom yang Anda butuhkan secara eksplisit.
  • Jangan takut JOIN (Tip 15). Saya sering mendengar orang berkata "hindari JOIN karena bikin lambat". Itu mitos. Database relasional diciptakan untuk JOIN. Yang bikin lambat itu bukan JOIN-nya, tapi JOIN pada kolom yang tidak di-INDEX, atau desain database yang buruk.
  • Yang harus Anda hindari adalah JOIN gaya lama (ANSI-89): FROM table1, table2 WHERE table1.id = table2.id. Ini berbahaya. Jika Anda lupa klausa WHERE, Anda akan mendapatkan Cartesian Product (setiap baris dikali setiap baris) yang bisa menghancurkan server Anda. Selalu gunakan sintaks modern (ANSI-92): FROM table1 JOIN table2 ON table1.id = table2.id.

👉 Apa yang bisa kamu lakukan sekarang:

Jadikan ini aturan pribadi: "Saya tidak akan pernah menulis SELECT * di file .sql yang saya simpan." (Untuk query cepat di tab baru, silakan saja). Lakukan audit pada kode Anda, cari FROM t1, t2 dan ganti menjadi sintaks JOIN...ON.

Konsep 10: Sabuk Pengaman Terakhir: SELECT sebelum UPDATE/DELETE (Tip 18)

Ini adalah SOP (Standar Operasional Prosedur) yang tidak bisa ditawar.

Insight yang Sering Terlewat:

Tidak ada tombol Ctrl+Z (Undo) di database produksi. Yang ada hanya "proses restorasi backup berjam-jam" dan "penjelasan memalukan kepada atasan".

Kesalahan paling umum adalah UPDATE atau DELETE dengan klausa WHERE yang salah (atau, yang terburuk, lupa klausa WHERE).

👉 Apa yang bisa kamu lakukan sekarang:

Jadikan ini muscle memory. Setiap kali Anda akan menulis UPDATE atau DELETE, selalu tulis sebagai SELECT * terlebih dahulu.

  1. Tulis: SELECT * FROM customers WHERE last_login < '2020-01-01';
  2. Lihat hasilnya. Apakah ini baris yang ingin Anda hapus? Apakah jumlahnya masuk akal?
  3. Jika sudah 100% yakin, baru ganti SELECT * menjadi DELETE.

Anda juga bisa membungkusnya dalam transaksi (BEGIN TRANSACTION; ... COMMIT;/ROLLBACK;) sebagai jaring pengaman tambahan.

🏁 Checklist Aksi Anda Mulai Hari Ini

Anda sudah mendapatkan ilmunya. Sekarang, lakukan praktiknya.

Checklist 1 Minggu ke Depan:

  • [ ] (Hari 1: Fondasi) Ambil 1 query lama Anda. Format ulang. Berikan alias yang jelas untuk setiap kolom fungsi dan tabel join.
  • [ ] (Hari 2: Struktur) Ambil 1 query rumit Anda (yang pakai subquery). Tulis ulang menggunakan WITH (CTE).
  • [ ] (Hari 3: Efisiensi) Cari 5 keyboard shortcut di editor SQL Anda dan gunakan seharian penuh.
  • [ ] (Hari 4: Integritas) Audit kode Anda. Cari satu SELECT * di kode produksi dan ganti dengan daftar kolom eksplisit.
  • [ ] (Hari 5: Performa) Ambil 1 query lambat. Buka Execution Plan-nya. Coba cari tahu di mana letak "Table Scan"-nya.
  • [ ] (Hari 6: Keamanan) Latihlah kebiasaan SELECT sebelum DELETE. Buat satu dummy table, masukkan data, lalu praktikkan siklus SELECT * ... -> DELETE ...
  • [ ] (Hari 7: Profesionalisme) Buat 1 repository Git dan commit skrip .sql Anda yang paling penting ke sana.

Ingat, menulis SQL itu mudah. Menulis SQL yang hebat butuh latihan dan disiplin. Selamat bekerja.



🏛️ Glosarium SQL: Dari Awam Menjadi Ahli

Berikut adalah istilah-istilah kunci dari materi tersebut, dijelaskan dengan analogi agar mudah menempel di kepala.

1. Alias (Column & Table)

  • Apa itu: Nama panggilan atau label sementara yang Anda berikan untuk kolom atau tabel di dalam query Anda.
  • Analogi (Nama Panggilan): Anda tidak memanggil teman Anda "Muhammad Faisal Abdau" setiap saat. Anda mungkin memanggilnya "Faisal". Di SQL, Anda tidak mau mengetik data_penjualan_per_kategori_produk berulang-ulang. Anda cukup menyebutnya p (untuk table alias) atau total_jual (untuk column alias).
  • Studi Kasus:
    • Tanpa Alias: SELECT data_pelanggan.nama_depan FROM data_pelanggan; (Repot)
    • Dengan Alias: SELECT dp.nama_depan FROM data_pelanggan AS dp; (Simpel)

2. CTE (Common Table Expression)

  • Apa itu: Sebuah "sub-query" sementara yang Anda beri nama dan letakkan di atas kueri utama Anda (dimulai dengan WITH).
  • Analogi (Mise en Place / Persiapan Masak): Bayangkan Anda seorang koki. Sebelum memasak, Anda siapkan dulu semua bahan di mangkuk-mangkuk kecil: mangkuk 1 berisi bawang cincang, mangkuk 2 berisi ayam potong, mangkuk 3 berisi saus. CTE adalah mangkuk-mangkuk itu. Kueri utama Anda adalah resep finalnya, yang tinggal mengambil dari mangkuk-mangkuk yang sudah siap. Ini jauh lebih rapi daripada mencincang bawang sambil menumis.
  • Studi Kasus: Daripada query yang menumpuk (SELECT * FROM (SELECT * FROM (...))), Anda bisa pecah:SQL
    WITH 
  PelangganAktif AS ( ... ), 
  TransaksiTerakhir AS ( ... )
SELECT * FROM PelangganAktif JOIN TransaksiTerakhir ...

3. Window Function

  • Apa itu: Fungsi agregat (seperti SUM, AVG, COUNT) yang bisa bekerja pada "jendela" atau sekelompok baris, tanpa harus "meruntuhkan" baris-baris tersebut seperti GROUP BY.
  • Analogi (Leaderboard Balapan):
    • GROUP BY itu seperti hanya memberi tahu Anda juara 1 (satu baris).
    • Window Function itu seperti menampilkan seluruh daftar pembalap (semua baris), tapi di samping setiap nama, ada kolom tambahan yang menunjukkan ranking mereka (ROW_NUMBER()) atau rata-rata kecepatan seluruh timnya (AVG(...) OVER (PARTITION BY ...)). Anda dapat detail dan agregat sekaligus.
  • Studi Kasus: Menampilkan daftar setiap karyawan, gajinya, dan rata-rata gaji departemennya di baris yang sama.

4. Execution Plan (Query Plan)

  • Apa itu: Peta strategi internal yang dibuat oleh database untuk memberitahu Anda bagaimana ia akan menjalankan query Anda.
  • Analogi (Rute Google Maps): Anda meminta "Saya mau data X." Database tidak langsung jalan. Ia berpikir dulu dan membuat Execution Plan. "Oke, untuk dapat data X, saya akan ambil data dari tabel A dulu (pakai Index Seek), lalu saya gabung ke tabel B (pakai Hash Join). Oh, jangan lewat tabel C, itu Full Table Scan (macet total)."
  • Studi Kasus: Jika query Anda lambat, Anda cek Execution Plan-nya. Jika Anda melihat ada "Table Scan" di tabel 10 juta baris, Anda tahu di situlah masalahnya (seperti rute yang menyuruh Anda melewati jalan tikus yang macet).

5. Surrogate Key vs. Business Key (Primary Key)

  • Primary Key (PK): Kunci unik untuk setiap baris.
  • Business Key: Kunci unik yang punya makna di dunia nyata (contoh: No KTP, email, No. Telepon).
  • Surrogate Key: Kunci unik yang tidak punya makna bisnis, dibuat khusus untuk database (contoh: id angka 1, 2, 3... atau kode acak UUID).
  • Analogi (Kunci Loker):
    • Business Key itu seperti menggunakan KTP Anda untuk membuka loker gym. Ini unik, tapi apa jadinya jika KTP Anda hilang atau ganti? Sistemnya jadi repot.
    • Surrogate Key itu seperti Anda diberi kunci loker bernomor 27. Angka "27" tidak ada artinya di luar gym, tapi di dalam sistem gym itu, ia adalah pengenal unik yang sempurna untuk loker Anda. Jauh lebih aman dan stabil.
  • Studi Kasus: Selalu gunakan id INT AUTO_INCREMENT atau UUID sebagai PK. Jangan pernah gunakan email sebagai PK, karena email bisa berubah.

6. Normalization

  • Apa itu: Proses mengorganisasi data di database untuk mengurangi pengulangan (redundansi) data. Intinya: "Satu data, disimpan di satu tempat."
  • Analogi (Kontak Telepon): Bayangkan Anda menyimpan alamat teman Anda di setiap pesan SMS yang dia kirim. Jika dia pindah rumah, Anda harus mengedit ratusan SMS lama Anda untuk ganti alamat. Itu tidak efisien. Normalisasi adalah Anda membuat aplikasi "Kontak", di mana alamat teman Anda disimpan satu kali saja. SMS Anda tinggal merujuk ke "Kontak" itu. Kalau dia pindah, Anda ganti alamat di satu tempat saja.
  • Studi Kasus: Memisahkan data ke tabel Users dan Orders. Tabel Orders tidak menyimpan nama dan alamat lengkap user, tapi hanya menyimpan user_id yang merujuk ke tabel Users.

7. ERD (Entity Relationship Diagram)

  • Apa itu: Peta visual atau blueprint yang menunjukkan semua tabel di database Anda dan bagaimana mereka saling terhubung.
  • Analogi (Peta Silsilah Keluarga): ERD adalah pohon silsilah untuk data Anda. Ia menunjukkan siapa "orang tua" (Users) dan siapa "anak" (Posts), dan bagaimana mereka terhubung (garis relasi user_id).
  • Studi Kasus: Sebelum mulai membuat query kompleks, Anda lihat dulu ERD-nya agar tidak salah menyambungkan (JOIN) tabel.

👨‍🏫 Teks Anda untuk Mengajar (Feynman Technique)

Ini adalah teks yang bisa Anda gunakan saat mengobrol santai dengan teman yang ingin belajar SQL, atau bahkan hanya Anda baca keras-keras untuk diri sendiri.

(Mulai di sini...)

"Eh, lu lagi belajar SQL, ya? Gue juga lagi dalamin, nih. Gue baru sadar, ternyata banyak orang (termasuk gue dulu) bisa nulis SQL, tapi kodenya berantakan.

Bukan cuma soal query-nya jalan atau enggak. Tapi soal tiga hal: Keterbacaan, Efisiensi, dan Keamanan.

Contoh ya...

Pertama, soal Keterbacaan.

Lu pernah lihat query JOIN 5 tabel? Pusing, kan? Nah, ada yang namanya Alias sama CTE.

  • Alias itu kayak nama panggilan. Daripada nulis tabel_transaksi_harian terus-terusan, kita panggil aja th. Simpel.
  • CTE (Common Table Expression) itu lebih keren lagi. Anggap aja kayak mise en place kalau masak. Lo siapin dulu bahan-bahannya di mangkuk terpisah (WITH ...), baru di query utama tinggal 'masak' gabungin semuanya. Kodenya jadi kayak cerita, gampang dibaca dari atas ke bawah.

Kedua, soal Efisiensi.

Kadang query kita lambat banget, kan? Itu karena kita nggak tahu database-nya 'mikir' kayak gimana. Nah, ada yang namanya Execution Plan.

  • Itu kayak rute Google Maps buat query kita. Kalau query-nya lambat, kita bisa cek 'rute'-nya. Oh, ternyata database-nya milih jalan macet (misalnya Table Scan). Berarti kita harus bantu dia dengan bikin 'jalan tol' baru (yaitu INDEX).

Ketiga, soal Keamanan dan Stabilitas Data.

Ini yang paling krusial.

  • Satu, jangan pernah pakai 'data bisnis' kayak No KTP atau email buat jadi Primary Key. Kenapa? Karena data itu bisa berubah. Orang bisa ganti email. Kalau PK-nya ganti, semua relasi di database bisa rusak.
  • Analoginya kayak kunci loker. Jangan pakai KTP buat buka loker, repot kalau KTP-nya ganti. Pakai aja Surrogate Key, kayak kunci bernomor '27'. Angka '27' itu nggak ada artinya, tapi dia stabil dan unik buat sistem itu.
  • Terus, setiap kali mau nulis DELETE atau UPDATE... sumpah, ini penting banget... selalu tulis sebagai SELECT * dulu. Cek dulu data mana yang kena. Kalau udah yakin 100%, baru ganti SELECT * jadi DELETE. Nggak ada Ctrl+Z di database produksi.

Itu sih beberapa hal yang menurut gue penting banget. Bukan cuma soal 'bisa', tapi jadi 'profesional'. Gimana, kebayang nggak?"

(Selesai...)

👉 Apa yang bisa kamu lakukan sekarang (Next Step):

Coba ambil satu query lama yang pernah Anda buat. Praktikkan hal-hal ini:

  1. Refactor: Terapkan Alias di semua tabel dan kolom fungsi.
  2. Struktur Ulang: Jika ada sub-query di dalamnya, coba tulis ulang pakai CTE.
  3. Investigasi: Cek Execution Plan-nya. Apakah ada yang bisa diperbaiki?
  4. Ajarkan: Coba jelaskan query yang sudah Anda perbaiki itu ke teman Anda menggunakan analogi di atas.

Live: Belajar Clean Code & SOLID Principle dengan Bahasa Pemrograman Python