เริ่มจากข้อจำกัดของ PostgreSQL: หยุดบั๊กมุมขอบของ AI ตั้งแต่แรก

-- 1) Totals should never be negative ALTER TABLE invoices ADD CONSTRAINT invoices_total_nonnegative CHECK (total_cents >= 0);

-- 2) Enum-like allowed values without adding a custom type ALTER TABLE tickets ADD CONSTRAINT tickets_status_allowed CHECK (status IN ('new', 'open', 'waiting', 'closed'));

-- 3) Date order rules ALTER TABLE subscriptions ADD CONSTRAINT subscriptions_date_order CHECK (end_date IS NULL OR end_date >= start_date);

\nCHECK ที่ดีอ่านเข้าใจได้ทันที ปฏิบัติกับมันเหมือนเอกสารของข้อมูลของคุณ ชอบนิพจน์สั้น ๆ ชื่อ constraint ชัดเจน และรูปแบบที่คาดเดาได้\n\nCHECK ไม่ใช่เครื่องมือสำหรับทุกอย่าง หากกฎต้องมองหาแถวอื่น รวบรวมข้อมูล หรือเปรียบเทียบข้ามตาราง (ตัวอย่างเช่น "บัญชีไม่ควรเกินขีดจำกัดแผน") เก็บตรรกะนั้นไว้ในโค้ดแอป ทริกเกอร์ หรืองานพื้นหลังที่ควบคุมได้\n\n## UNIQUE: ป้องกันการซ้ำที่คุณจะเสียดายในภายหลัง\n\nกฎ `UNIQUE` ง่ายมาก: ฐานข้อมูลปฏิเสธไม่ให้เก็บสองแถวที่มีค่าซ้ำในคอลัมน์ที่ถูกจำกัด (หรือการรวมค่าหลายคอลัมน์) นี่กำจัดทั้งคลาสของบั๊กที่เกิดเมื่อเส้นทาง "สร้าง" ทำงานสองครั้ง เกิด retry หรือสองผู้ใช้ส่งข้อมูลพร้อมกัน\n\nUNIQUE ยืนยันว่าไม่มีค่าซ้ำสำหรับค่าที่คุณกำหนด มันไม่ได้รับประกันว่าค่าจะมีอยู่ (`NOT NULL`) ว่ามีรูปแบบที่ถูกต้อง (`CHECK`) หรือว่ามันตรงกับนิยามความเท่าเทียมของคุณ (ตัวพิมพ์ ช่องว่าง เครื่องหมายวรรคตอน) เว้นแต่คุณจะกำหนดไว้\n\nที่ที่มักต้องการ uniqueness ได้แก่ อีเมลในตารางผู้ใช้ `external_id` จากระบบอื่น หรือชื่อที่ต้องไม่ซ้ำภายในบัญชีเช่น `(account_id, name)`\n\nข้อควรระวังหนึ่งข้อ: NULL กับ UNIQUE ใน PostgreSQL NULL ถูกมองว่าเป็น "ไม่ทราบ" ดังนั้นค่า NULL หลายค่าอนุญาตภายใต้ UNIQUE constraint หากคุณหมายความว่า "ค่าต้องมีอยู่และต้องไม่ซ้ำ" ให้รวม UNIQUE กับ `NOT NULL`\n\nรูปแบบที่ใช้ได้จริงสำหรับตัวระบุที่เห็นโดยผู้ใช้คือความไม่ซ้ำแบบไม่สนใจตัวพิมพ์ ผู้คนจะพิมพ์ "[email protected]" แล้วต่อมาพิมพ์ "[email protected]" และคาดหวังว่ามันคือคนเดียวกัน\n\n```sql
-- Case-insensitive unique email
CREATE UNIQUE INDEX users_email_unique_ci
ON users (lower(email));

-- Unique contact name per account
ALTER TABLE contacts
ADD CONSTRAINT contacts_account_name_unique UNIQUE (account_id, name);

\nกำหนดความหมายของ "ซ้ำ" สำหรับผู้ใช้ของคุณ (ตัวพิมพ์ ช่องว่าง ต่อบัญชีหรือทั่วระบบ) แล้วเข้ารหัสมันครั้งเดียวเพื่อให้ทุกเส้นทางโค้ดปฏิบัติตามกฎเดียวกัน\n\n## FOREIGN KEY: รักษาความสอดคล้องของความสัมพันธ์\n\nFOREIGN KEY พูดว่า "แถวนี้ต้องชี้ไปยังแถวจริงที่นู่น" หากไม่มีมัน โค้ดอาจสร้างเรคอร์ดกำพร้าที่ดูถูกต้องเมื่อแยกกันแต่ทำลายแอปในภายหลัง ตัวอย่างเช่น โน้ตที่อ้างถึงลูกค้าที่ถูกลบ หรือใบแจ้งหนี้ที่ชี้ไปยัง user ID ที่ไม่เคยมีอยู่\n\nคีย์ต่างประเทศสำคัญที่สุดเมื่อสองการกระทำเกิดขึ้นใกล้กัน: การลบและการสร้าง, การ retry หลัง timeout, หรือการทำงานของงานพื้นหลังด้วยข้อมูลล้าสมัย ฐานข้อมูลดีกว่าที่จะบังคับความสอดคล้องกว่าที่ทุกเส้นทางแอปจะต้องจำการตรวจสอบเอง\n\n### เลือกพฤติกรรม ON DELETE ที่เหมาะสม\n\nตัวเลือก ON DELETE ควรตรงกับความหมายในโลกจริงของความสัมพันธ์ ถามตัวเองว่า: "ถ้าพ่อแม่หายไป ลูกยังควรอยู่ไหม?"\n\n- RESTRICT (หรือ NO ACTION): บล็อกการลบพ่อเมือยังมีลูกอยู่\n- CASCADE: ลบพ่อแม่ก็ลบลูกด้วย\n- SET NULL: เก็บลูกไว้แต่เอาลิงก์ออก\n\nระวัง CASCADE มันอาจถูกต้อง แต่ก็อาจลบมากกว่าที่คาดเมื่อเกิดบั๊กหรือแอดมินเผลอลบเรคอร์ดพ่อแม่\n\n### สคีมาแบบ multi-tenant: แสดงความเป็นเจ้าของอย่างชัดเจน\n\nในแอป multi-tenant foreign key ไม่ได้เกี่ยวกับความถูกต้องเท่านั้น มันยังป้องกันการรั่วไหลข้ามบัญชี รูปแบบหนึ่งที่พบได้บ่อยคือรวม account_id ในทุกตารางที่เป็นของ tenant และเชื่อมความสัมพันธ์ผ่านมัน\n\n```sql CREATE TABLE contacts ( account_id bigint NOT NULL, id bigint GENERATED ALWAYS AS IDENTITY, PRIMARY KEY (account_id, id) );

CREATE TABLE notes ( account_id bigint NOT NULL, id bigint GENERATED ALWAYS AS IDENTITY, contact_id bigint NOT NULL, body text NOT NULL, PRIMARY KEY (account_id, id), FOREIGN KEY (account_id, contact_id) REFERENCES contacts (account_id, id) ON DELETE RESTRICT );

\nนี่บังคับว่า "ใครเป็นเจ้าของอะไร" ในสคีมา: โน้ตไม่สามารถชี้ไปยัง contact ในบัญชีอื่นได้ แม้ว่าโค้ดแอป (หรือ query ที่ LLM สร้าง) จะพยายามทำเช่นนั้น\n\n## ทีละขั้นตอน: เพิ่มข้อจำกัดโดยไม่ทำให้โปรดักชันพัง\n\nเริ่มด้วยการเขียนรายการ invariant สั้น ๆ: ข้อเท็จจริงที่ต้องเป็นจริงเสมอ เขียนให้ชัดเจน เช่น "ทุก contact ต้องมี email" "สถานะต้องเป็นหนึ่งในค่าที่อนุญาต" "ใบแจ้งหนี้ต้องเป็นของลูกค้าที่จริงอยู่" นี่คือกฎที่คุณต้องการให้ฐานข้อมูลบังคับทุกครั้ง\n\nค่อย ๆ เปิดตัวการเปลี่ยนแปลงด้วยมิเกรชันขนาดเล็กเพื่อไม่ให้โปรดักชันถูกเซอร์ไพรส์:\n\n- เพิ่มคอลัมน์หรือกฎใหม่ในวิธีที่ไม่ทำให้ระบบพังก่อน\n- เติมข้อมูลย้อนหลังในแบตช์\n- แก้ไขข้อมูลเสีย (dedupe, แก้ค่าที่ไม่ถูกต้อง) หรือกักมันไว้สำหรับทบทวน\n- บังคับกฎ (`NOT NULL`, `UNIQUE`, `CHECK`, `FOREIGN KEY`)\n- ทำให้พฤติกรรมแอปเข้มงวดขึ้นเพื่อให้จัดการข้อผิดพลาดชัดเจน\n\nส่วนที่ยุ่งคือข้อมูลเสียที่มีอยู่ วางแผนสำหรับมัน สำหรับค่าซ้ำ ให้เลือกแถวผู้ชนะ รวมที่เหลือไว้ และเก็บบันทึกเล็ก ๆ สำหรับการตรวจสอบ สำหรับฟิลด์ที่หาย ให้เลือกค่าเริ่มต้นที่ปลอดภัยเฉพาะเมื่อปลอดภัยจริง ๆ มิฉะนั้นกักข้อมูลไว้ สำหรับความสัมพันธ์ที่พัง ให้ระบุผู้ปกครองที่ถูกต้องให้กับแถวลูกหรือเอาแถวที่ผิดออก\n\nหลังการมิเกรชันแต่ละครั้ง ให้ตรวจสอบด้วยการเขียนไม่กี่รายการที่ควรล้มเหลว: แทรกแถวที่ขาดค่าที่จำเป็น, แทรกคีย์ซ้ำ, แทรกค่าที่อยู่นอกช่วง, และอ้างอิงแถวพ่อแม่ที่หายไป การเขียนที่ล้มเหลวเป็นสัญญาณที่มีประโยชน์ มันแสดงให้เห็นว่าโค้ดส่วนที่ผ่านมาพึ่งพาพฤติกรรม "พยายามอย่างดีที่สุด" อย่างเงียบ ๆ อยู่ที่ไหนบ้าง\n\n## ตัวอย่างที่สมจริง: CRM เล็ก ๆ ที่คงความสะอาด\n\nนึกภาพ CRM เล็ก ๆ: accounts (ลูกค้าของ SaaS คุณ), บริษัทที่พวกเขาทำงานด้วย, contacts ที่บริษัทเหล่านั้น และ deals ที่ผูกกับบริษัท\n\nนี่คือแอปประเภทที่คนมักสร้างอย่างรวดเร็วด้วยเครื่องมือแชท มันดูโอเคในการสาธิต แต่ข้อมูลจริงจะยุ่งเร็ว ปัญหาสองอย่างที่มักเกิดเร็วคือ: contact ซ้ำ (อีเมลเดิมถูกกรอกสองครั้งในรูปแบบต่างกันเล็กน้อย) และ deals ถูกสร้างโดยไม่มี company เพราะเส้นทางโค้ดบางทางลืมตั้ง `company_id` อีกเรื่องคลาสสิกคือค่า deal เป็นลบหลังรีแฟกเตอร์หรือความผิดพลาดในการ parse\n\nการแก้ไม่ใช่การเพิ่ม if-statement มากขึ้น แต่มันคือการเลือกข้อจำกัดไม่กี่ข้อที่ทำให้ข้อมูลเสียเป็นไปไม่ได้ที่จะเก็บ\n\n### ข้อจำกัดที่ช่วยให้ CRM สะอาด\n\n```sql
-- Contacts: prevent duplicates per account
ALTER TABLE contacts
  ADD CONSTRAINT contacts_account_email_uniq UNIQUE (account_id, email);

-- Deals: require a company and keep the relationship valid
ALTER TABLE deals
  ALTER COLUMN company_id SET NOT NULL,
  ADD CONSTRAINT deals_company_fk
    FOREIGN KEY (company_id) REFERENCES companies(id);

-- Deals: deal value cannot be negative
ALTER TABLE deals
  ADD CONSTRAINT deals_value_nonneg CHECK (deal_value >= 0);

-- A few obvious required fields
ALTER TABLE companies
  ALTER COLUMN name SET NOT NULL;
ALTER TABLE contacts
  ALTER COLUMN email SET NOT NULL;

\nนี่ไม่ใช่การเข้มงวดโดยไม่มีเหตุผล คุณกำลังเปลี่ยนความคาดหวังที่คลุมเครือให้เป็นกฎที่ฐานข้อมูลสามารถบังคับได้ทุกครั้ง ไม่ว่าโค้ดส่วนใดของแอปจะเขียนข้อมูล\n\n### อะไรเปลี่ยนในแอปหลังจากนั้น\n\nเมื่อข้อจำกัดเหล่านี้อยู่ แอปจะเรียบง่ายขึ้น คุณสามารถเอาการตรวจสอบป้องกันหลายอย่างที่พยายามตรวจจับซ้ำทีหลังออกได้ ความล้มเหลวจะชัดเจนและจัดการได้ (เช่น "email มีอยู่แล้วในบัญชีนี้" แทนพฤติกรรมแปลก ๆ ในภายหลัง) และเมื่อ route ที่สร้างโดยเครื่องมือหลงลืมฟิลด์หรือจัดการค่าผิด การเขียนจะล้มเหลวทันทีแทนที่จะทำให้ฐานข้อมูลเสียแบบเงียบ ๆ\n\n## ข้อผิดพลาดทั่วไปที่ทำให้ข้อจำกัดเจ็บปวด\n\nข้อจำกัดทำงานได้ดีที่สุดเมื่อมันสอดคล้องกับการทำงานจริงของธุรกิจ ความเจ็บปวดส่วนใหญ่เกิดจากการเพิ่มกฎที่ดู "ปลอดภัย" ตอนนั้น แต่กลายเป็นความประหลาดใจในภายหลัง\n\nกับดักทั่วไปคือการใช้ ON DELETE CASCADE ทุกที่ มันดูเรียบร้อยจนกว่าจะมีคนลบแถวพ่อแม่และฐานข้อมูลลบครึ่งระบบไปด้วย Cascades อาจถูกต้องสำหรับข้อมูลที่เป็นของจริง ๆ (เช่น รายการบรรทัดร่างที่ไม่ควรมีอยู่คนเดียว) แต่เสี่ยงกับบันทึกสำคัญ (ลูกค้า ใบแจ้งหนี้ ตั๋ว) หากไม่แน่ใจ ให้เลือก RESTRICT แล้วจัดการการลบอย่างตั้งใจ\n\nปัญหาอีกอย่างคือเขียน CHECK ที่แคบเกินไป "สถานะต้องเป็น 'new', 'won', หรือ 'lost'" ฟังดูโอเคจนกว่าคุณต้องการ "paused" หรือ "archived" ข้อจำกัด CHECK ที่ดีอธิบายความจริงที่คงที่ ไม่ใช่ตัวเลือก UI ชั่วคราว "amount >= 0" อยู่ได้ดี ส่วน "country in (...)" มักจะไม่อยู่ยาว\n\nปัญหาบ่อยเมื่อทีมเพิ่มข้อจำกัดหลังจากโค้ดที่สร้างแล้วเริ่มใช้งานคือ:\n\n- ใช้ CASCADE เป็นเครื่องมือทำความสะอาดแล้วลบข้อมูลมากกว่าที่ตั้งใจ\n- เขียน CHECK ที่แคบจนบล็อกกรณีอนาคตที่ถูกต้อง\n- คิดว่า UNIQUE หยุดการซ้ำเมื่อเกี่ยวกับ NULL\n- เปลี่ยนกฎโดยไม่มีแผนแก้แถวที่ผิดอยู่แล้ว\n\nเรื่องประสิทธิภาพ: PostgreSQL จะสร้าง index ให้กับ UNIQUE โดยอัตโนมัติ แต่ foreign keys จะไม่สร้างดัชนีให้คอลัมน์ที่อ้างอิงโดยอัตโนมัติ หากไม่มีดัชนีนั้น การอัปเดตและการลบบนพ่อแม่อาจช้าเพราะ Postgres ต้องสแกนตารางลูกเพื่อตรวจสอบการอ้างอิง\n\nก่อนจะเข้มงวดกับกฎ ใส่ใจหาแถวที่มีอยู่แล้วที่จะล้มเหลวกับกฎนั้น ตัดสินใจแก้หรือกักไว้ และปล่อยการเปลี่ยนแปลงเป็นขั้นตอน\n\n## เช็คลิสต์ด่วนและขั้นตอนถัดไปสำหรับงานถัดไปของคุณ\n\nก่อนปล่อย ให้ใช้เวลาห้านาทีต่อตารางแล้วเขียนลงว่าต้องเป็นจริงอย่างไร หากคุณพูดเป็นภาษาอังกฤษชัดเจน มันมักบังคับได้ด้วยข้อจำกัด\n\nถามคำถามเหล่านี้สำหรับแต่ละตาราง:\n\n- อะไรที่ไม่ควรเป็น NULL?\n- อะไรที่ไม่ควรถูกทำซ้ำ?\n- อะไรที่ไม่ควรเป็นค่าลบหรืออยู่นอกช่วง?\n- อะไรที่ไม่ควรมีอยู่หากไม่มีพ่อแม่ (ไม่มีแถวกำพร้า)?\n- อะไรที่ควรปฏิบัติตามกฎง่าย ๆ เสมอ (สถานะที่อนุญาต เริ่มก่อนจบ)?\n\nหากคุณใช้เครื่องมือสร้างด้วยแชท ให้ถือ invariant เหล่านั้นเป็นเกณฑ์การรับงานสำหรับข้อมูล ไม่ใช่โน้ตทางเลือก ตัวอย่าง: "จำนวนดีลต้องไม่เป็นลบ" "อีเมลคอนแทคไม่ซ้ำต่อ workspace" "งานต้องอ้างอิง contact จริง" ยิ่งกฎชัดเจนเท่าไร โอกาสเกิดมุมขอบโดยไม่ได้ตั้งใจก็น้อยลงเท่านั้น\n\nKoder.ai (koder.ai) รวมฟีเจอร์เช่น โหมดวางแผน snapshots และการย้อนกลับ รวมถึงการส่งออกซอร์สโค้ด ซึ่งช่วยให้คุณวน iterate การเปลี่ยนสคีมาอย่างปลอดภัยเมื่อค่อย ๆ เข้มงวดกับข้อจำกัดตามกาลเวลา\n\nรูปแบบการเปิดตัวที่ง่ายและใช้ได้จริงกับทีมจริง: เลือกตารางที่ให้คุณค่ามากที่สุด (users, orders, invoices, contacts), เพิ่ม 1-2 ข้อจำกัดที่ป้องกันความล้มเหลวร้ายแรงที่สุด (มักเป็น NOT NULL และ UNIQUE), แก้การเขียนที่ล้มเหลว แล้วทำซ้ำ การค่อย ๆ เข้มงวดกว่ามิเกรชันใหญ่อันเสี่ยง\n