SQL Dasar
untuk Backend API

Deklaratif, bukan imperatif seperti loop JavaScript

Di Laravel, Eloquent sering membuat SQL terasa tersembunyi. Di Go, kita justru lebih dekat dengan SQL, karena repository sengaja dibuat eksplisit, mudah dibaca saat code review, dan mudah diuji.

SQL adalah bahasa deklaratif untuk membaca dan mengubah data relasional. Kamu tidak menulis langkah per langkah seperti for di JavaScript. Kamu menyatakan data seperti apa yang dibutuhkan, lalu PostgreSQL yang memilih cara eksekusinya lewat komponen bernama query planner. Ini pergeseran cara berpikir yang penting: dari “bagaimana mengambil” menjadi “apa yang diambil”.

Modul ini fokus pada satu hal: menulis SQL yang akurat dan aman, dengan tabel skincare yang sama persis seperti yang akan kita pakai di repository pgx nanti. Kita belum memanggil database dari Go di sini (itu dimulai di chapter koneksi pgx), tetapi setiap query sudah ditulis dengan placeholder $1 agar tinggal disalin ke kode Go tanpa perombakan.

Untuk rujukan resmi, modul ini selaras dengan dokumentasi PostgreSQL 18 tentang SELECT, INSERT, RETURNING, LIMIT/OFFSET, serta aggregate function dan join.

Tabel kanonik yang dipakai sepanjang Roadmap 3

Sebelum query, kita kunci dulu skema. Tabel di bawah ini adalah subset kanonik online shop skincare yang akan dipakai semua chapter Roadmap 3, jadi nama tabel dan kolomnya tidak boleh berubah-ubah.

Inti penjualan skincare bukan produk, melainkan variant. Satu produk (misalnya “Gentle Cleanser”) punya banyak variant (ukuran 100ml dan 200ml, atau shade berbeda), dan justru variant inilah yang memegang harga lewat kolom price_rupiah serta punya sku unik. cart_items dan order_items mengacu ke variant_id, bukan ke produk langsung.

migrations/000002_catalog.up.sql (subset)Salin
CREATE TABLE brands (
  id          bigint GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
  slug        text NOT NULL UNIQUE,
  name        text NOT NULL,
  created_at  timestamptz NOT NULL DEFAULT now()
);

CREATE TABLE products (
  id          bigint GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
  brand_id    bigint NOT NULL REFERENCES brands(id),
  slug        text NOT NULL UNIQUE,
  name        text NOT NULL,
  status      text NOT NULL DEFAULT 'draft'
                CHECK (status IN ('draft', 'active', 'archived')),
  created_at  timestamptz NOT NULL DEFAULT now(),
  deleted_at  timestamptz
);

CREATE TABLE product_variants (
  id            bigint GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
  product_id    bigint NOT NULL REFERENCES products(id) ON DELETE CASCADE,
  sku           text NOT NULL UNIQUE,
  variant_name  text NOT NULL,
  size_label    text,
  shade         text,
  price_rupiah  bigint NOT NULL CHECK (price_rupiah >= 0),
  is_active     boolean NOT NULL DEFAULT true,
  created_at    timestamptz NOT NULL DEFAULT now()
);

migrations/000005_orders.up.sql (subset)Salin
CREATE TABLE orders (
  id              bigint GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
  user_id         bigint NOT NULL REFERENCES users(id),
  order_number    text NOT NULL UNIQUE,
  status          text NOT NULL DEFAULT 'pending'
                    CHECK (status IN ('pending','paid','processing','shipped','completed','cancelled','refunded')),
  subtotal_rupiah bigint NOT NULL CHECK (subtotal_rupiah >= 0),
  total_rupiah    bigint NOT NULL CHECK (total_rupiah >= 0),
  placed_at       timestamptz NOT NULL DEFAULT now(),
  created_at      timestamptz NOT NULL DEFAULT now()
);

CREATE TABLE order_items (
  id                bigint GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
  order_id          bigint NOT NULL REFERENCES orders(id) ON DELETE CASCADE,
  variant_id        bigint NOT NULL REFERENCES product_variants(id),
  product_name      text NOT NULL,   -- snapshot saat checkout
  sku               text NOT NULL,   -- snapshot saat checkout
  unit_price_rupiah bigint NOT NULL CHECK (unit_price_rupiah >= 0),
  quantity          integer NOT NULL CHECK (quantity > 0)
);

erDiagram
  USERS ||--o{ ORDERS : places
  BRANDS ||--o{ PRODUCTS : owns
  PRODUCTS ||--o{ PRODUCT_VARIANTS : has
  PRODUCT_VARIANTS ||--o{ CART_ITEMS : selected_as
  CARTS ||--o{ CART_ITEMS : contains
  ORDERS ||--o{ ORDER_ITEMS : contains
  PRODUCT_VARIANTS ||--o{ ORDER_ITEMS : snapshot_from

Gambar 1. ERD subset skincare untuk latihan SQL. Variant memegang harga; cart dan order item mengacu ke variant.

Kenapa WHERE tidak bisa memakai alias dari SELECT

Satu sumber kebingungan terbesar pendatang baru SQL: query ditulis dengan urutan SELECT ... FROM ... WHERE, tetapi PostgreSQL mengevaluasinya dengan urutan logis yang sangat berbeda. Memahami urutan ini menjelaskan banyak error sekaligus.

Urutan kamu menulis klausa bukan urutan database memprosesnya. Secara logis, PostgreSQL mulai dari FROM (tentukan sumber baris), lalu menyaring dengan WHERE, mengelompokkan dengan GROUP BY, menyaring grup dengan HAVING, baru kemudian menghitung kolom SELECT, mengurutkan dengan ORDER BY, dan terakhir memotong dengan LIMIT/OFFSET.

flowchart LR
  FROM["FROM / JOIN<br/>kumpulkan baris sumber"] --> WHERE["WHERE<br/>saring baris"]
  WHERE --> GROUP["GROUP BY<br/>kelompokkan"]
  GROUP --> HAVING["HAVING<br/>saring grup"]
  HAVING --> SELECT["SELECT<br/>hitung kolom & alias"]
  SELECT --> ORDER["ORDER BY<br/>urutkan"]
  ORDER --> LIMIT["LIMIT / OFFSET<br/>potong halaman"]

Gambar 2. Urutan eksekusi logis. SELECT dievaluasi setelah WHERE dan GROUP BY, itulah sebabnya alias kolom belum tersedia di WHERE.

Konsekuensi praktis pertama: alias yang kamu definisikan di SELECT belum ada saat WHERE berjalan. Query berikut akan error karena harga belum dikenal di tahap WHERE.

salah.sqlSalin
-- ERROR: column "harga" does not exist
SELECT price_rupiah AS harga
FROM product_variants
WHERE harga <= 200000;

Solusinya: pakai ekspresi aslinya di WHERE, atau pakai alias di ORDER BY (yang memang berjalan setelah SELECT).

benar.sqlSalin
SELECT price_rupiah AS harga
FROM product_variants
WHERE price_rupiah <= 200000   -- ekspresi asli, bukan alias
ORDER BY harga ASC;            -- alias boleh di sini, ORDER BY setelah SELECT

Query yang menggerakkan hampir setiap endpoint baca

SELECT adalah query paling sering muncul di backend API karena hampir semua endpoint membaca data sebelum merespons client.

Bentuk dasarnya SELECT kolom FROM tabel WHERE kondisi. Pilih kolom yang benar-benar dibutuhkan. Jangan refleks memakai SELECT * di endpoint produksi: ia menarik kolom yang tidak perlu, membuat kontrak ke struct Go rapuh, dan gampang membocorkan kolom internal.

queries/list-active-variants.sqlSalin
SELECT id, product_id, sku, variant_name, price_rupiah
FROM product_variants
WHERE is_active = true;

Untuk detail produk publik, kita cari dengan slug, karena slug enak dipakai di URL. id dipakai untuk relasi internal.

queries/product-detail-by-slug.sqlSalin
SELECT id, brand_id, slug, name, status, created_at
FROM products
WHERE slug = 'gentle-cleanser'
  AND status = 'active'
  AND deleted_at IS NULL;

WHERE untuk filter katalog

Filter produk skincare biasanya datang dari query parameter React app: brand, harga maksimum, dan status stok. Operator perbandingan (=, <>, <=, >=), BETWEEN, IN, dan pencocokan teks ILIKE (case-insensitive) adalah perkakas sehari-hari.

queries/variant-filter.sqlSalin
SELECT id, sku, variant_name, shade, price_rupiah
FROM product_variants
WHERE is_active = true
  AND price_rupiah BETWEEN 50000 AND 250000
  AND variant_name ILIKE '%toner%';

IN cocok untuk menyaring beberapa nilai sekaligus, misalnya beberapa status order.

queries/orders-by-status.sqlSalin
SELECT id, order_number, status, total_rupiah
FROM orders
WHERE status IN ('paid', 'processing', 'shipped');

Bukan sekadar null JavaScript, ini logika tiga-nilai

NULL di SQL berarti “tidak diketahui”, dan ia mengikuti aturan logika tiga-nilai (true, false, unknown). Salah memahami ini adalah sumber bug filter yang paling sering lolos sampai produksi.

Aturan kunci: apa pun yang dibandingkan dengan NULL lewat = atau <> menghasilkan unknown, bukan true atau false. Dan WHERE hanya meloloskan baris yang kondisinya bernilai true. Maka WHERE deleted_at = NULL tidak pernah meloloskan baris apa pun, walau niatmu mencari yang belum dihapus.

null-salah-vs-benar.sqlSalin
-- SALAH: = NULL menghasilkan unknown, baris tidak pernah lolos
SELECT id FROM products WHERE deleted_at = NULL;

-- BENAR: pakai IS NULL / IS NOT NULL
SELECT id FROM products WHERE deleted_at IS NULL;      -- belum dihapus
SELECT id FROM products WHERE deleted_at IS NOT NULL;  -- sudah soft-deleted

NULL dalam aggregate dan COALESCE

COUNT(*) menghitung semua baris, tetapi COUNT(kolom) melewati baris yang kolomnya NULL. SUM dan AVG juga mengabaikan NULL. Saat kamu butuh angka 0 alih-alih NULL (misalnya total belanja customer yang belum pernah order), bungkus dengan COALESCE.

coalesce-default.sqlSalin
-- COALESCE mengembalikan argumen pertama yang bukan NULL
SELECT
  u.id,
  COALESCE(SUM(o.total_rupiah), 0) AS total_spent_rupiah
FROM users u
LEFT JOIN orders o ON o.user_id = u.id
GROUP BY u.id;

Dapatkan id baru tanpa query kedua

Di PostgreSQL, RETURNING sangat penting untuk backend Go, karena kita hampir selalu butuh id (atau kolom yang dibuat database) segera setelah insert, tanpa harus melakukan SELECT susulan.

Bentuk dasarnya INSERT INTO tabel (kolom) VALUES (nilai) RETURNING id. PostgreSQL mendukung RETURNING pada perintah yang memodifikasi baris (INSERT, UPDATE, DELETE), dan ini menghemat satu round-trip ke database.

queries/create-variant.sqlSalin
INSERT INTO product_variants
  (product_id, sku, variant_name, size_label, price_rupiah)
VALUES
  (1, 'GC-100ML', 'Gentle Cleanser 100ml', '100ml', 129000)
RETURNING id;

Untuk response 201 Created, kita sering ingin mengembalikan seluruh data baris baru, termasuk kolom yang diisi default oleh database (seperti created_at dan is_active).

queries/create-variant-full.sqlSalin
INSERT INTO product_variants
  (product_id, sku, variant_name, size_label, price_rupiah)
VALUES
  (1, 'GC-200ML', 'Gentle Cleanser 200ml', '200ml', 199000)
RETURNING id, sku, variant_name, price_rupiah, is_active, created_at;

Insert cart item

Saat customer menambahkan item ke cart, cart_items menyimpan cart_id, variant_id, dan quantity. Perhatikan: cart item tidak menyimpan harga. Harga dibaca segar dari product_variants saat checkout, supaya cart selalu memantulkan harga terkini.

queries/add-cart-item.sqlSalin
INSERT INTO cart_items (cart_id, variant_id, quantity)
VALUES (10, 7, 2)
RETURNING id, cart_id, variant_id, quantity, created_at;

Perintah yang wajib dijaga ketat dengan WHERE

UPDATE dan DELETE terlihat sederhana, tetapi di backend nyata keduanya selalu harus dibatasi dengan WHERE yang jelas. Satu klausa yang lupa bisa mengubah seluruh tabel.

UPDATE mengubah baris yang sudah ada. Untuk admin katalog, query umum adalah mengubah harga, nama, atau status aktif variant. Gabungkan dengan RETURNING agar handler langsung punya data terbaru untuk dikirim ke client.

queries/update-variant-price.sqlSalin
UPDATE product_variants
SET price_rupiah = 139000
WHERE id = 7
RETURNING id, sku, price_rupiah;

DELETE menghapus baris secara fisik. Untuk data transaksi (order, payment), ini hampir selalu salah karena riwayat audit hilang. Untuk item cart, hard delete masuk akal karena cart bersifat sementara.

queries/delete-cart-item.sqlSalin
DELETE FROM cart_items
WHERE id = 15
  AND cart_id = 10;

Soft delete: hapus tanpa menghapus

Soft delete berarti baris tidak benar-benar dihapus. Kita isi kolom deleted_at, lalu semua query publik menambahkan filter deleted_at IS NULL. Pola ini menjaga riwayat (produk yang sudah pernah dibeli tetap bisa dirujuk order lama) sambil menyembunyikannya dari katalog.

queries/soft-delete-product.sqlSalin
UPDATE products
SET deleted_at = now(),
    status = 'archived'
WHERE id = 1
  AND deleted_at IS NULL
RETURNING id, status, deleted_at;

queries/public-products.sqlSalin
-- Katalog publik selalu menyaring yang sudah soft-deleted
SELECT id, slug, name, status
FROM products
WHERE deleted_at IS NULL
  AND status = 'active';

Pagination untuk katalog, order history, dan dashboard

Pagination adalah kebutuhan harian: product listing, order history, dan tabel admin semuanya butuh memotong hasil menjadi halaman.

ORDER BY menentukan urutan baris, LIMIT membatasi jumlah, dan OFFSET melewati sejumlah baris di awal. PostgreSQL mengingatkan bahwa tanpa ORDER BY yang deterministik, urutan baris tidak dijamin, sehingga LIMIT/OFFSET bisa memberi halaman yang acak atau tumpang tindih.

queries/products-page-1.sqlSalin
SELECT id, slug, name, created_at
FROM products
WHERE deleted_at IS NULL
  AND status = 'active'
ORDER BY created_at DESC, id DESC   -- tie-breaker id agar deterministik
LIMIT 20
OFFSET 0;

Halaman kedua dengan per_page = 20 memakai OFFSET 20. Rumusnya offset = (page - 1) * per_page.

queries/products-page-2.sqlSalin
SELECT id, slug, name, created_at
FROM products
WHERE deleted_at IS NULL
  AND status = 'active'
ORDER BY created_at DESC, id DESC
LIMIT 20
OFFSET 20;

Sort dari harga termurah

queries/variants-cheapest-first.sqlSalin
SELECT id, sku, variant_name, price_rupiah
FROM product_variants
WHERE is_active = true
ORDER BY price_rupiah ASC, id ASC
LIMIT 12
OFFSET 0;

Menggabungkan beberapa tabel dalam satu response

Relasi tabel menjadi nyata saat API perlu menggabungkan data dari beberapa tabel dalam satu response, misalnya menampilkan variant beserta nama produk dan brand-nya.

INNER JOIN hanya mengembalikan baris yang punya pasangan di kedua tabel. Untuk halaman katalog yang menampilkan variant beserta produk dan brand, ini tepat: kita hanya mau variant yang memang terhubung ke produk yang ada.

queries/variants-with-product.sqlSalin
SELECT
  v.id            AS variant_id,
  v.sku,
  v.variant_name,
  v.price_rupiah,
  p.name          AS product_name,
  b.name          AS brand_name
FROM product_variants v
INNER JOIN products p ON p.id = v.product_id
INNER JOIN brands b   ON b.id = p.brand_id
WHERE v.is_active = true
  AND p.deleted_at IS NULL
  AND p.status = 'active'
ORDER BY p.name ASC, v.price_rupiah ASC;

LEFT JOIN mengembalikan semua baris tabel kiri, walau tabel kanan tidak punya pasangan. Kolom dari sisi kanan akan NULL untuk baris tak berpasangan. Ini berguna untuk admin, misalnya menemukan produk yang belum punya variant agar segera dilengkapi.

queries/products-without-variants.sqlSalin
SELECT
  p.id   AS product_id,
  p.name AS product_name,
  v.id   AS variant_id
FROM products p
LEFT JOIN product_variants v ON v.product_id = p.id
WHERE p.deleted_at IS NULL
  AND v.id IS NULL   -- hanya produk yang TIDAK punya variant
ORDER BY p.name ASC;

flowchart LR
  O["orders<br/>(1 baris order)"] -->|order_id| OI["order_items<br/>(banyak baris item)"]
  OI -->|variant_id| V["product_variants<br/>(harga, sku)"]
  V -->|product_id| P["products<br/>(nama, brand_id)"]
  P -->|brand_id| B["brands<br/>(nama brand)"]

Gambar 3. Rantai JOIN untuk menampilkan detail order lengkap: dari order ke item, ke variant, ke produk, ke brand.

Untuk menampilkan detail satu order lengkap dengan nama produk dan brand, kita rantai beberapa join. Perhatikan, untuk laporan order kita pakai kolom snapshot (oi.product_name, oi.unit_price_rupiah) agar harga historis akurat, dan join ke katalog hanya untuk data yang memang ingin “fresh”.

queries/order-detail.sqlSalin
SELECT
  o.order_number,
  o.status,
  oi.product_name,           -- snapshot saat checkout
  oi.unit_price_rupiah,      -- snapshot saat checkout
  oi.quantity,
  b.name AS current_brand    -- data katalog terkini (boleh berbeda)
FROM orders o
INNER JOIN order_items oi      ON oi.order_id = o.id
INNER JOIN product_variants v  ON v.id = oi.variant_id
INNER JOIN products p          ON p.id = v.product_id
INNER JOIN brands b            ON b.id = p.brand_id
WHERE o.id = $1
ORDER BY oi.id ASC;

Mengubah banyak baris menjadi angka ringkas

Aggregate query meringkas banyak baris menjadi angka, cocok untuk dashboard, ringkasan order, dan laporan penjualan. GROUP BY mengelompokkan, HAVING menyaring grup.

Fungsi aggregate inti: COUNT (jumlah baris), SUM (penjumlahan), AVG (rata-rata), MIN/MAX (nilai ekstrem). GROUP BY membagi baris menjadi grup, lalu aggregate dihitung per grup.

queries/order-count-per-user.sqlSalin
SELECT
  u.id        AS user_id,
  u.email,
  COUNT(o.id) AS total_orders
FROM users u
LEFT JOIN orders o ON o.user_id = u.id
GROUP BY u.id, u.email
ORDER BY total_orders DESC;

Untuk total nilai belanja per customer, gunakan SUM. Karena LEFT JOIN bisa menghasilkan NULL untuk customer tanpa order, COALESCE(SUM(...), 0) mengubahnya menjadi 0.

queries/customer-spending.sqlSalin
SELECT
  u.id        AS user_id,
  u.email,
  COUNT(o.id) AS total_orders,
  COALESCE(SUM(o.total_rupiah), 0) AS total_spent_rupiah
FROM users u
LEFT JOIN orders o ON o.user_id = u.id
   AND o.status IN ('paid', 'completed')   -- hanya order yang benar dibayar
GROUP BY u.id, u.email
ORDER BY total_spent_rupiah DESC;

HAVING: menyaring setelah dikelompokkan

WHERE menyaring baris sebelum dikelompokkan; HAVING menyaring grup setelah aggregate dihitung. Untuk menemukan “customer VIP” yang sudah belanja lebih dari 1 juta rupiah, syarat itu memakai hasil SUM, sehingga harus di HAVING, bukan WHERE.

queries/vip-customers.sqlSalin
SELECT
  u.id,
  u.email,
  SUM(o.total_rupiah) AS total_spent_rupiah
FROM users u
INNER JOIN orders o ON o.user_id = u.id
WHERE o.status IN ('paid', 'completed')   -- saring baris dulu (sebelum grup)
GROUP BY u.id, u.email
HAVING SUM(o.total_rupiah) > 1000000      -- saring grup (setelah aggregate)
ORDER BY total_spent_rupiah DESC;

Variant terlaris

Menggabungkan join dan aggregate untuk laporan: variant mana yang paling banyak terjual, memakai snapshot di order_items.

queries/best-selling-variants.sqlSalin
SELECT
  oi.sku,
  oi.product_name,
  SUM(oi.quantity)                          AS units_sold,
  SUM(oi.unit_price_rupiah * oi.quantity)   AS revenue_rupiah
FROM order_items oi
INNER JOIN orders o ON o.id = oi.order_id
WHERE o.status IN ('paid', 'completed', 'shipped')
GROUP BY oi.sku, oi.product_name
ORDER BY units_sold DESC
LIMIT 10;

Pemisahan perintah dan data, garis pertahanan utama

Query API tidak boleh menyisipkan input user langsung ke string SQL. Gunakan parameter agar nilai dan perintah SQL tetap terpisah. Ini bukan sekadar gaya, ini pertahanan keamanan paling fundamental terhadap SQL injection.

Di PostgreSQL, placeholder parameter ditulis berdasarkan posisi: $1, $2, $3, dan seterusnya. Ini berbeda dari MySQL/PDO yang memakai ?. Nilai yang dikirim sebagai argumen tidak pernah ditafsirkan sebagai SQL, ia selalu diperlakukan sebagai data murni.

queries/variant-search-parameterized.sqlSalin
SELECT id, sku, variant_name, price_rupiah
FROM product_variants
WHERE is_active = true
  AND variant_name ILIKE $1
  AND price_rupiah <= $2
ORDER BY price_rupiah ASC, id ASC
LIMIT $3
OFFSET $4;

Bandingkan langsung cara berbahaya dan cara aman saat dipanggil dari Go dengan pgx. Yang aman membuat driver mengirim template dan nilai secara terpisah ke server, sehingga input tidak mungkin “keluar” dari posisinya sebagai data.

Contoh pemanggilan dari Go dengan pgxpool

Inilah preview cara query parameterized dipanggil dari Go. Kita belum membahas pgx secara penuh (itu chapter berikutnya), tetapi perhatikan tiga hal idiomatik: context.Context sebagai parameter pertama, SQL sebagai konstanta, dan nilai dioper sebagai argumen di belakang.

internal/product/repository.goSalin
package product

import (
	"context"
	"errors"

	"github.com/jackc/pgx/v5"
	"github.com/jackc/pgx/v5/pgxpool"
)

type Variant struct {
	ID          int64
	SKU         string
	VariantName string
	PriceRupiah int64
}

type Repository struct {
	pool *pgxpool.Pool
}

func NewRepository(pool *pgxpool.Pool) *Repository {
	return &Repository{pool: pool}
}

func (r *Repository) FindVariantBySKU(ctx context.Context, sku string) (Variant, error) {
	const query = `
SELECT id, sku, variant_name, price_rupiah
FROM product_variants
WHERE sku = $1
  AND is_active = true`

	var v Variant
	err := r.pool.QueryRow(ctx, query, sku).Scan(
		&v.ID,
		&v.SKU,
		&v.VariantName,
		&v.PriceRupiah,
	)
	if errors.Is(err, pgx.ErrNoRows) {
		return Variant{}, ErrVariantNotFound
	}
	if err != nil {
		return Variant{}, err
	}
	return v, nil
}

Pemetaan langsung dari yang sudah kamu kuasai

Karena kamu kuat di JavaScript, cara tercepat menjinakkan SQL adalah memetakannya ke array method yang sudah kamu pakai setiap hari. Hampir setiap klausa SQL punya padanan langsung.

Gambar 4. Peta padanan array method JavaScript ke klausa SQL.

Yang membuat SQL bukan sekadar “array method di database” adalah dua hal. Pertama, urutan eksekusi logis tetap (WHERE selalu sebelum SELECT), tidak sebebas merangkai method. Kedua, dan ini pembeda nyata, SQL mengeksekusi semuanya dekat data lalu hanya mengirim hasil akhir lewat jaringan.

Tiga query yang siap dibawa ke repository

Latihan ini menyusun tiga query nyata yang langsung bisa kamu pindahkan ke repository produk, cart, dan order di chapter pgx. Semuanya sudah memakai placeholder $1 dan kolom kanonik.

hands-on/01-list-catalog.sqlSalin
SELECT
  v.id            AS variant_id,
  v.sku,
  v.variant_name,
  v.price_rupiah,
  p.name          AS product_name,
  b.name          AS brand_name
FROM product_variants v
INNER JOIN products p ON p.id = v.product_id
INNER JOIN brands b   ON b.id = p.brand_id
WHERE v.is_active = true
  AND p.deleted_at IS NULL
  AND p.status = 'active'
ORDER BY p.created_at DESC, v.id DESC
LIMIT $1
OFFSET $2;

hands-on/02-add-cart-item.sqlSalin
INSERT INTO cart_items (cart_id, variant_id, quantity)
VALUES ($1, $2, $3)
RETURNING id, cart_id, variant_id, quantity, created_at;

hands-on/03-order-history.sqlSalin
SELECT
  o.id              AS order_id,
  o.order_number,
  o.status,
  o.total_rupiah,
  o.placed_at,
  COUNT(oi.id)      AS line_count,
  SUM(oi.quantity)  AS total_items
FROM orders o
INNER JOIN order_items oi ON oi.order_id = o.id
WHERE o.user_id = $1
GROUP BY o.id, o.order_number, o.status, o.total_rupiah, o.placed_at
ORDER BY o.placed_at DESC, o.id DESC
LIMIT $2
OFFSET $3;

Checklist sebelum query masuk repository

• Semua input user memakai $1, $2, bukan string concatenation.
• SELECT mengambil kolom eksplisit, bukan *.
• UPDATE dan DELETE selalu punya WHERE yang membatasi baris, plus kunci pemilik.
• Filter nullable memakai IS NULL / IS NOT NULL, bukan = NULL.
• Pagination memakai ORDER BY deterministik dengan tie-breaker id.
• Kolom hasil JOIN diberi alias agar mudah di-scan ke struct Go.
• Kolom non-aggregate di query GROUP BY ikut dicantumkan di GROUP BY.

flowchart LR
  HTTP["HTTP Handler (chi)"] --> DTO["Parse query params"]
  DTO --> SVC["Service: validasi bisnis"]
  SVC --> REPO["Repository: SQL + args $1..$n"]
  REPO --> PG[("PostgreSQL")]
  PG --> REPO
  REPO --> SVC
  SVC --> HTTP

Gambar 5. Posisi SQL dalam alur request API Go. SQL hidup di lapisan repository, dipanggil dengan argumen parameterized.

Fondasi sebelum pgxpool, transaksi, dan repository

SQL dasar di modul ini adalah fondasi sebelum kita menyentuh pgxpool, transaksi, dan repository pattern di chapter-chapter berikutnya Roadmap 3.