Wawancara Data Engineering: Masalah Apa yang Dipecahkan oleh NOT ENFORCED di PostgreSQL 18?

Pertanyaan dan skenario

Tabel orders warisan memuat sejumlah kecil nilai customer_id tanpa pelanggan induk (parent customer). Tim ingin mendeklarasikan relasi tersebut di PostgreSQL 18 agar skema target menjadi eksplisit, tanpa memblokir perbaikan data historis yang dilakukan sekaligus. Tentukan apakah NOT ENFORCED cocok, jelaskan perbedaannya dengan foreign key biasa, tunjukkan cara menemukan pelanggaran, dan definisikan peralihan bertahap beserta bukti bahwa data telah siap.

Hal yang diuji oleh pewawancara

Membedakan intensi bisnis yang dideklarasikan dari penolakan database terhadap penulisan yang tidak valid.
Menjelaskan bahwa NOT ENFORCED tidak memeriksa penulisan data dan oleh karena itu bukan merupakan jaminan integritas runtime yang lengkap.
Merancang pemindaian historis, pemantauan inkremental, batch perbaikan, dan gerbang peralihan (switch gate) akhir.
Mengidentifikasi risiko dump, restore, penulis lintas-layanan (cross-service writers), rollback, dan kompatibilitas klien.
Menjelaskan mengapa batasan yang belum diverifikasi tidak boleh diperlakukan sebagai asumsi oleh pengoptimal kueri (query optimizer).

Pertanyaan klarifikasi sebelum menjawab

Apakah ini foreign key atau batasan CHECK? Berapa volume pelanggaran, tingkat pertumbuhan, dan siapa penanggung jawab perbaikannya?
Apakah penulisan data terbatas pada PostgreSQL, atau apakah tugas ETL, skrip batch, dan alat langsung melewati (bypass) aplikasi?
Bisakah klien warisan menangani nama batasan baru, kunci migrasi (migration lock), dan kegagalan peralihan?
Haruskah peralihan akhir mencapai nol pelanggaran, atau dapat diselesaikan per penyewa (tenant by tenant)?
Bukti apa yang memastikan bahwa setiap partisi dan penanda air (watermark) telah dipindai?

Kerangka jawaban 30 detik

“NOT ENFORCED berguna untuk mendeklarasikan intensi batasan CHECK atau foreign key selagi data kotor warisan masih ada; PostgreSQL tidak akan memeriksa penulisan baru untuk batasan tersebut, sehingga ini bukan jaminan integritas. Saya akan menetapkan dasar pelanggaran penuh, menjalankan pemeriksaan inkremental serta peringatan untuk penulisan baru, memperbaiki atau mengarantina baris historis, dan beralih ke enforced hanya setelah mencapai nol pelanggaran serta uji coba restore berhasil. Selama masa transisi, klien dan pengoptimal kueri tidak boleh memperlakukan deklarasi tersebut sebagai kebenaran yang terverifikasi.”

Jawaban mendalam langkah demi langkah

Nyatakan semantik dan risikonya

PostgreSQL 18 memungkinkan batasan CHECK dan foreign key ditentukan sebagai NOT ENFORCED. Database menyimpan deklarasi tersebut tetapi tidak memeriksa operasi penulisan sebagaimana mestinya pada batasan enforced. Metadata ini mendukung dokumentasi, tata kelola, dan koordinasi migrasi; fitur ini tidak menggantikan aplikasi, ETL, atau pemeriksaan kualitas data independen.

Bangun bukti menyeluruh dan inkremental

Untuk foreign key, jalankan anti-join guna menemukan baris turunan tanpa induk; untuk CHECK, jalankan negasi dari predikat tersebut. Catat waktu pemindaian, snapshot atau watermark, rentang partisi, dan ringkasan hasil (result digest). Kemudian periksa operasi insert dan update di CDC, tugas penulisan, atau tugas kualitas data sehingga pemindaian historis satu kali tidak menutupi jalur bypass baru.

sql

SELECT o.order_id, o.customer_id
FROM orders AS o
LEFT JOIN customers AS c ON c.customer_id = o.customer_id
WHERE o.customer_id IS NOT NULL
  AND c.customer_id IS NULL;

Rancang gerbang perbaikan dan peralihan

Klasifikasikan pesanan yatim menjadi dapat diperbaiki secara otomatis, memerlukan konfirmasi bisnis, atau memerlukan karantina. Berikan kunci idempoten (idempotency key), batas batch, dan kondisi berhenti pada proses perbaikan. Sebelum beralih, wajibkan hasil pemindaian penuh bernilai nol, jendela inkremental yang bersih, uji coba pencadangan dan pemulihan (backup-and-restore drill) yang sukses, serta cakupan atas setiap proses penulis. Jalankan migrasi enforced pada jendela lalu lintas rendah dan pantau antrean kunci (lock waits) serta tingkat kesalahan.

Tangani pemulihan dan pergeseran lingkungan

Jika migrasi gagal, pertahankan deklarasi NOT ENFORCED dan data yang telah diperbaiki, lakukan rollback pada rilis aplikasi dan tugas kualitas data, serta jangan mengklaim bahwa batasan tersebut enforced. Uji dump, restore, replika baca, kluster pemulihan bencana (disaster-recovery), dan klien lama. Pastikan bahwa lingkungan target memahami metadata conenforced alih-alih hanya mengandalkan tampilan ORM.

Contoh jawaban berkualitas tinggi

“Saya memperlakukan NOT ENFORCED sebagai kontrak migrasi, bukan pagar pengaman database. Saya akan menjalankan anti-join menyeluruh pada orders dan customers, mencatat partisi dan watermark, lalu membiarkan CDC memeriksa operasi penulisan baru. Data yatim diklasifikasikan ke dalam perbaikan otomatis, konfirmasi bisnis, dan karantina, dengan pemutaran ulang idempoten. Hanya setelah pemeriksaan penuh dan inkremental bersih, pengujian restore berhasil, dan setiap penulis tercakup, barulah saya mengalihkan foreign key ke status enforced pada jendela lalu lintas rendah dan memantau lock waits. Klien atau pengoptimal kueri tidak boleh berasumsi bahwa deklarasi tersebut membuktikan integritas.”

Kesalahan umum

Kesalahan: Melihat foreign key di skema dan berasumsi bahwa data sudah konsisten → Penyebab kegagalan: NOT ENFORCED tidak memeriksa operasi penulisan → Koreksi: Hasilkan bukti kualitas penuh dan inkremental.
Kesalahan: Hanya memindai tabel historis satu kali → Penyebab kegagalan: Penulis bypass baru dapat menciptakan pelanggaran → Koreksi: Cakup penulisan dari CDC, ETL, skrip, dan aplikasi.
Kesalahan: Langsung beralih ke enforced → Penyebab kegagalan: Data kotor atau lock dapat menggagalkan migrasi → Koreksi: Perbaiki, lakukan simulasi, pasang gerbang verifikasi, lalu alihkan di jendela lalu lintas rendah.
Kesalahan: Memperlakukan deklarasi yang tidak ditegakkan sebagai petunjuk optimasi (optimization hint) → Penyebab kegagalan: Deklarasi bukanlah bukti integritas → Koreksi: Hanya andalkan statistik yang terverifikasi dan perilaku database yang didukung.

Pertanyaan lanjutan dan jawabannya

Bisakah batasan CHECK merujuk ke tabel lain untuk aturan lintas tabel?

Jangan mengandalkannya. CHECK tingkat baris tidak dapat menjamin kondisi global setelah baris lain berubah, dan urutan dump/restore dapat mengekspos kelemahan tersebut. Lebih baik gunakan foreign key atau tugas kualitas data independen untuk relasi lintas tabel.

Bagaimana jika jumlah pelanggaran tidak pernah mencapai nol?

Pertahankan NOT ENFORCED, tempatkan pelanggaran dalam karantina atau daftar pengecualian bisnis yang eksplisit, serta tetapkan batas pertumbuhan, penanggung jawab, dan tanggal kedaluwarsa. Jika batasan tersebut lebih berfungsi sebagai dokumentasi daripada kontrak yang dapat dieksekusi dalam waktu dekat, evaluasi kembali apakah batasan tersebut memang perlu berada di dalam skema.

Bisakah validasi aplikasi menggantikan foreign key yang enforced?

Hanya sebagai masa transisi atau pelengkap. Berbagai proses penulis, konkurensi, dan skrip langsung dapat melewati pemeriksaan aplikasi; batas integritas akhir harus berupa batasan database atau pipeline data yang dapat diverifikasi.

Bagaimana cara membuktikan bahwa replika pemulihan bencana (disaster-recovery) belum bergeser?

Jalankan kueri kualitas data yang sama pada replika primer dan replika yang dipulihkan, bandingkan watermark, jumlah pelanggaran, dan ringkasan hasil, serta sertakan simulasi restore dalam gerbang peralihan.

Referensi

Dokumentasi PostgreSQL 18: Constraints
Dokumentasi PostgreSQL 18: CREATE TABLE
Dokumentasi PostgreSQL 18: Catatan Rilis
Greg Low: Wawancara SQL: 64 Menonaktifkan dan mengaktifkan kembali batasan
MockIF: Pertanyaan Wawancara SQL 2026

Tips menjawab

Nyatakan bahwa NOT ENFORCED mendeklarasikan batasan tanpa memeriksa penulisan, kemudian jelaskan baseline, pemantauan inkremental, kelas perbaikan, gerbang peralihan, dan bukti restore.

Poin penting dalam satu kalimat

NOT ENFORCED adalah kontrak migrasi yang terlihat; data engineer tetap memerlukan bukti independen sebelum menerapkan perlindungan runtime yang ditegakkan (enforced).