db-schema

name	db-schema
description	ออกแบบหรือรีวิว schema ฐานข้อมูลจาก query pattern จริง — normalize ให้พอดี, เลือก key/index/constraint ตามการใช้งาน, และวางแผน migration แบบ expand-contract ที่ไม่ทำ production ล่ม (มีข้อมูลอยู่แล้วย้ายยังไง, rollback ได้ไหม, zero-downtime) Trigger on "ออกแบบ db", "ออกแบบ schema", "รีวิว schema", "วางแผน migration", "แก้ตาราง", or when the user is designing tables or changing a live schema.

db-schema — ออกแบบจากคำถามที่จะถามข้อมูล ไม่ใช่จากหน้าตาข้อมูล

Phase 0 — เริ่มจาก access pattern

ก่อนวาดตาราง ถามให้ได้ว่า แอปจะ query อะไรบ่อยสุด — schema ถูกออกแบบมารับใช้ query ไม่ใช่รับใช้ความสวยของ ER diagram:

• อ่านหนักหรือเขียนหนัก? อ่านแบบไหน (by id? by ช่วงเวลา? full-text? aggregate?)
• ความสัมพันธ์: 1-1, 1-N, N-N (ต้องมีตารางเชื่อม)
• ข้อมูลโตทางไหน (แถวเพิ่มเรื่อยๆ แบบ log? หรือคงที่?)
• ถ้ามี schema เดิม: อ่านของจริงก่อน (\d, migration files) — ต่อยอด ไม่รื้อโดยไม่จำเป็น

Phase 1 — หลักออกแบบ

เรื่อง	กติกา
Normalize	เริ่มที่ 3NF เป็น default — denormalize เฉพาะเมื่อมี query pattern จริงที่พิสูจน์ว่าต้องการ ไม่ใช่กันไว้ก่อน
Primary key	ชอบ surrogate key (bigint identity / UUID) — UUID ดีตอน distributed/ซ่อนจำนวน แต่แพงกว่าตอน index; natural key เป็น PK ระวังวันที่มันเปลี่ยน
Foreign key + constraint	ประกาศ FK จริง, NOT NULL ตรงที่ควร, UNIQUE, CHECK — ให้ DB กันข้อมูลพัง อย่าฝากไว้กับ app layer อย่างเดียว
ชนิดข้อมูล	เงิน = integer หน่วยย่อย หรือ decimal ห้าม float; เวลา = timestamptz เก็บ UTC; enum ใช้ค่าที่ query ได้ ไม่ใช่ magic number ลอย
Index	สร้างตาม WHERE/JOIN/ORDER BY จริง; composite ลำดับ equality ก่อน range; อย่าหว่าน index เพราะทุกตัวมีค่า write
Soft vs hard delete	ต้อง audit/กู้คืนไหม → soft delete (deleted_at) พร้อม partial index กรองแถวเป็น; ไม่งั้น hard delete ตรงไปตรงมากว่า
Nullable	ทุกคอลัมน์ที่ nullable ต้องตอบได้ว่า null หมายความว่าอะไร — ถ้าตอบไม่ได้ ควร NOT NULL + default

Phase 2 — Migration ที่ไม่ล่ม (สำคัญสุดเมื่อมีข้อมูลจริง)

ตารางเปล่าแก้ยังไงก็ได้ — ตารางที่มีข้อมูล + มีแอปวิ่งอยู่ ต้อง expand-contract:

1. Expand — เพิ่มของใหม่แบบ backward-compatible: คอลัมน์ใหม่เป็น nullable หรือมี default; ยังไม่ลบ/ไม่ rename ของเก่า
2. Migrate + dual-write — code เขียนทั้งเก่าและใหม่; backfill ข้อมูลเดิมเป็น batch (ไม่ UPDATE ทั้งตารางรวดเดียวจนล็อก)
3. Contract — เมื่อ backfill ครบและ code ไม่อ่านของเก่าแล้ว ค่อยลบคอลัมน์เก่า

• rename คือกับดัก: rename ตรงๆ = ช่วงหนึ่ง code เก่ากับ schema ใหม่อยู่ด้วยกันไม่ได้ → ทำเป็น add ใหม่ + dual-write + drop เก่า แทน
• ทุก migration ต้องตอบ: rollback ยังไง ถ้า deploy แล้วพัง; op ที่ล็อกตารางนาน (add index บนตารางใหญ่) ใช้ CONCURRENTLY/online DDL
• add column NOT NULL โดยไม่มี default บนตารางใหญ่ = ล็อก/rewrite — เพิ่ม nullable ก่อน แล้ว backfill แล้วค่อยใส่ constraint

Phase 3 — Output

• DDL จริง (CREATE TABLE / ALTER) รันได้ + เหตุผลย่อของแต่ละ constraint/index สำคัญ
• ถ้าเป็น migration: ลำดับขั้น expand-contract + สคริปต์ backfill + แผน rollback
• วาดความสัมพันธ์ให้เห็นภาพ (ตาราง + FK) เมื่อมีหลายตารางเกี่ยวกัน

กติกา

• ทุก index/denormalization ต้องชี้ query ที่มันรับใช้ได้ — ไม่มี query รองรับ = ยังไม่ต้องมี
• syntax/behavior เฉพาะ DB (Postgres vs MySQL online DDL, partial index) ที่ไม่แน่ใจ เช็คเอกสารจริงก่อน
• มีข้อมูล production จริง — ย้ำเรื่อง backup ก่อน migrate และทดสอบบน copy ก่อนเสมอ