Temu Duga Kejuruteraan Data: Apakah Masalah yang Diselesaikan oleh PostgreSQL 18 NOT ENFORCED?

Soalan dan senario

Jadual orders legasi mengandungi sejumlah kecil nilai customer_id tanpa pelanggan induk. Pasukan ingin mengisytiharkan perhubungan tersebut dalam PostgreSQL 18 supaya skema sasaran adalah eksplisit, tanpa menyekat pembaikan data sejarah secara one-shot. Tentukan sama ada NOT ENFORCED sesuai, terangkan perbezaannya dengan kunci asing biasa, tunjukkan cara mencari pelanggaran, dan takrifkan peralihan berperingkat berserta bukti bahawa data telah sedia.

Perkara yang diuji oleh penemu duga

Membezakan niat perniagaan yang diisytiharkan daripada penolakan penulisan tidak sah oleh pangkalan data.
Menerangkan bahawa NOT ENFORCED tidak memeriksa penulisan dan oleh itu bukanlah jaminan integriti masa jalanan (runtime) yang lengkap.
Mereka bentuk imbasan sejarah, pemantauan berperingkat (incremental), kelompok pembaikan, dan get peralihan akhir.
Mengenal pasti risiko dump, restore, penulis merentas perkhidmatan, rollback, dan keserasian klien.
Menerangkan sebab kekangan yang belum disahkan tidak boleh dianggap sebagai andaian pengoptimum pertanyaan (query optimizer).

Soalan penjelasan sebelum menjawab

Adakah ini kunci asing atau CHECK? Berapakah jumlah pelanggaran, kadar pertumbuhan, dan pemilik pembaikan?
Adakah penulisan terhad kepada PostgreSQL, atau adakah tugas ETL, skrip kelompok, dan alatan terus memintas aplikasi?
Bolehkah klien legasi mengendalikan nama kekangan baharu, kunci migrasi, dan peralihan yang gagal?
Adakah peralihan akhir mesti mencapai sifar pelanggaran, atau bolehkah ia selesai mengikut penyewa (tenant demi tenant)?
Apakah bukti yang membuktikan bahawa setiap partisi dan tera air (watermark) telah diimbas?

Rangka jawapan 30 saat

“NOT ENFORCED berguna untuk mengisytiharkan niat CHECK atau kunci asing sementara data kotor legasi masih wujud; PostgreSQL tidak akan memeriksa penulisan baharu untuknya, jadi ia bukan jaminan integriti. Saya akan menetapkan garis dasar pelanggaran penuh, menjalankan pemeriksaan berperingkat dan makluman untuk penulisan baharu, membaiki atau mengkuarantin baris sejarah, dan beralih kepada enforced hanya selepas sifar pelanggaran dan latihan pemulihan (restore drill). Semasa peralihan, klien dan pengoptimum tidak boleh menganggap pengisytiharan tersebut sebagai kebenaran yang telah disahkan.”

Jawapan mendalam langkah demi langkah

Nyatakan semantik dan risiko

PostgreSQL 18 membenarkan kekangan CHECK dan kunci asing ditentukan sebagai NOT ENFORCED. Pangkalan data menyimpan pengisytiharan tersebut tetapi tidak memeriksa penulisan seperti yang dilakukan untuk kekangan yang dikuatkuasakan (enforced). Metadata ini menyokong dokumentasi, tadbir urus, dan penyelarasan migrasi; ia tidak menggantikan pemeriksaan kualiti data oleh aplikasi, ETL, atau pemeriksaan bebas.

Bina bukti penuh dan berperingkat

Untuk kunci asing, jalankan anti-join untuk mencari baris anak tanpa induk; untuk CHECK, jalankan penafian predikat tersebut. Catatkan masa imbasan, snapshot atau watermark, julat partisi, dan ringkasan hasil (result digest). Kemudian periksa operasi insert dan update dalam CDC, tugas penulisan, atau tugas kualiti supaya imbasan sejarah sekali sahaja tidak menyembunyikan laluan pintasan baharu.

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;

Reka bentuk pembaikan dan get peralihan

Klasifikasikan pesanan yatim kepada boleh dibaiki secara automatik, memerlukan pengesahan perniagaan, atau memerlukan kuarantin. Berikan pembaikan kunci kedapulan (idempotency key), had kelompok, dan syarat henti. Sebelum beralih, wajibkan imbasan penuh sifar pelanggaran, tetingkap berperingkat yang bersih, latihan sandaran-dan-pemulihan yang berjaya, serta liputan setiap penulis. Jalankan migrasi enforced dalam tetingkap trafik rendah dan perhatikan penantian kunci (lock waits) serta kadar ralat.

Kendalikan pemulihan dan hanyutan persekitaran (environment drift)

Jika migrasi gagal, kekalkan pengisytiharan NOT ENFORCED dan rekod yang telah dibaiki, undurkan keluaran aplikasi dan tugas kualiti, serta jangan mendakwa kekangan tersebut telah dikuatkuasakan. Uji dump, restore, replika bacaan, kluster pemulihan bencana, dan klien lama. Sahkan bahawa persekitaran sasaran memahami metadata conenforced berbanding hanya bergantung pada paparan ORM.

Contoh jawapan berkualiti tinggi

“Saya menganggap NOT ENFORCED sebagai kontrak migrasi, bukan benteng kawalan pangkalan data. Saya akan menjalankan anti-join lengkap ke atas jadual pesanan dan pelanggan, merekod partisi dan watermark, kemudian membiarkan CDC memeriksa penulisan baharu. Rekod yatim diklasifikasikan kepada pembaikan automatik, pengesahan perniagaan, dan kuarantin, dengan main semula idempoten. Hanya selepas pemeriksaan penuh dan berperingkat bersih, ujian pemulihan lulus, dan setiap penulis diliputi, barulah saya menukar kunci asing kepada enforced dalam tetingkap trafik rendah serta memantau lock wait. Pada bila-bila masa pun klien atau pengoptimum pertanyaan tidak boleh menganggap bahawa pengisytiharan tersebut membuktikan integriti.”

Ralat lazim

Ralat: Melihat kunci asing dalam skema dan menganggap data adalah konsisten → Sebab ia gagal: NOT ENFORCED tidak memeriksa penulisan → Pembetulan: Hasilkan bukti kualiti penuh dan berperingkat.
Ralat: Mengimbas jadual sejarah sekali sahaja → Sebab ia gagal: Penulis pintasan baharu boleh mencipta pelanggaran → Pembetulan: Liputi penulisan CDC, ETL, skrip, dan aplikasi.
Ralat: Beralih terus kepada enforced → Sebab ia gagal: Data kotor atau kunci (locks) boleh membatalkan migrasi → Pembetulan: Baiki, latih, tetapkan get, kemudian beralih dalam tetingkap trafik rendah.
Ralat: Menganggap pengisytiharan tidak dikuatkuasakan sebagai petunjuk pengoptimuman → Sebab ia gagal: Pengisytiharan bukanlah bukti integriti → Pembetulan: Bergantung hanya pada statistik yang disahkan dan kelakuan pangkalan data yang disokong.

Soalan susulan dan respons

Bolehkah kekangan CHECK merujuk jadual lain untuk peraturan merentas jadual?

Jangan bergantung padanya. CHECK pada peringkat baris tidak dapat menjamin keadaan global selepas baris lain berubah, dan susunan dump/restore boleh mendedahkan kelemahan tersebut. Lebih baik gunakan kunci asing atau tugas kualiti bebas untuk perhubungan merentas jadual.

Bagaimana jika bilangan pelanggaran tidak pernah mencapai sifar?

Kekalkan NOT ENFORCED, letakkan pelanggaran dalam kuarantin atau senarai pengecualian perniagaan yang eksplisit, dan tetapkan had pertumbuhan, pemilik, serta tarikh luput. Jika kekangan tersebut hanyalah dokumentasi dan bukannya kontrak yang boleh dilaksanakan dalam masa terdekat, nilai semula sama ada ia wajar berada dalam skema.

Bolehkah pengesahan aplikasi menggantikan kunci asing yang dikuatkuasakan?

Hanya sebagai peralihan atau pelengkap. Penulis berganda, keserentakan (concurrency), dan skrip terus memintas pemeriksaan aplikasi; sempadan integriti akhir mestilah kekangan pangkalan data atau saluran paip data yang boleh disahkan.

Bagaimanakah anda membuktikan replika pemulihan bencana tidak mengalami hanyutan (drift)?

Jalankan pertanyaan kualiti yang sama pada replika utama dan replika yang dipulihkan, bandingkan watermark, bilangan pelanggaran, dan digest hasil, serta sertakan latihan pemulihan dalam get peralihan.

Rujukan

Dokumentasi PostgreSQL 18: Constraints
Dokumentasi PostgreSQL 18: CREATE TABLE
Dokumentasi PostgreSQL 18: Release Notes
Greg Low: Temu Duga SQL: 64 Melumpuhkan dan mengaktifkan semula kekangan
MockIF: Soalan Temu Duga SQL 2026

Tip menjawab

Nyatakan bahawa NOT ENFORCED mengisytiharkan kekangan tanpa memeriksa penulisan, kemudian berikan garis dasar, pemantauan berperingkat, kelas pembaikan, get peralihan, dan bukti pemulihan.

Rumusan satu ayat

NOT ENFORCED ialah kontrak migrasi yang jelas kelihatan; jurutera data masih memerlukan bukti bebas sebelum menggunakan perlindungan masa jalanan yang dikuatkuasakan.