Natural key — ใช้ของที่มีอยู่แล้ว#

แนวคิด: เอาคอลัมน์ที่มีความหมายในชีวิตจริงและไม่ซ้ำกันมาทำเป็น PK เลย ตัวอย่าง

• ตาราง customers ใช้ email เป็น PK (เพราะอีเมลแต่ละคนไม่ซ้ำกัน)
• ตาราง employees ใช้ national_id เป็น PK
• ตาราง products ใช้ sku_code เป็น PK

ข้อดี: ไม่ต้องสร้างคอลัมน์ใหม่ คนอ่าน data เห็นแล้วเข้าใจทันที

ข้อเสีย: สิ่งที่คิดว่า “ไม่มีวันเปลี่ยน” เปลี่ยนได้เสมอครับ

• ลูกค้าเปลี่ยนอีเมล → ทุกที่ที่อ้าง email ต้องตามแก้พร้อมกัน
• คนเปลี่ยนชื่อนามสกุล (แต่งงาน) → ถ้าใช้ full_name เป็น key ตายเลย
• รัฐบาลเปลี่ยนรูปแบบเลขบัตร — เคยเจอ pattern ของวงการที่ระบบทั้งระบบล่ม
• email = PII (Personally Identifiable Information) — ใช้เป็น key แล้วเอาไป log, share API, debug เสี่ยงเรื่อง privacy

Surrogate key — สร้างเลขขึ้นมาเอง#

แนวคิด: สร้างคอลัมน์ id แยกต่างหาก ให้ database สร้างเลขให้อัตโนมัติ (auto-increment 1, 2, 3, … หรือใช้ UUID ที่เป็นเลขสุ่ม 36 ตัวอักษร)

ข้อดี:

• ไม่มีความหมายในชีวิตจริง — ไม่มีวันเปลี่ยน
• ไม่ใช่ PII — เอาไปแชร์ใน log/API ได้ปลอดภัย
• เป็นเลขสั้น — JOIN เร็ว, index ขนาดเล็ก
• application logic ไม่ต้องสนใจว่า business rule เปลี่ยนหรือไม่

ข้อเสีย: ต้องเสียคอลัมน์เพิ่มมา 1 ช่อง (น้อยมาก) คนอ่าน data ดิบไม่เข้าใจว่า “id 4521 คือใคร” ต้อง JOIN ตารางอื่น

ในวงการปี 2026 surrogate key คือ default choice 95% ของระบบใหม่ใช้ surrogate key (id = bigint auto-increment หรือ UUID) แล้วเก็บ email/national_id/sku เป็นคอลัมน์ปกติที่บังคับ unique constraint ได้ทั้งความยืดหยุ่น + ความปลอดภัย + ความเร็ว

ทีนี้พอมีหลายตาราง คำถามต่อมาคือ ตาราง orders จะรู้ได้ยังไงว่า order ใบนี้เป็นของลูกค้าคนไหน? คำตอบคือ Foreign Key

Referential Integrity — กฎเหล็กของ FK#

พอมี FK แล้ว database จะบังคับกฎที่เรียกว่า referential integrity แปลว่า “ความถูกต้องของการอ้างอิง” กฎมี 2 ข้อ

1. สร้าง order ที่ชี้ไปที่ customer_id ที่ไม่มี = ไม่ได้ — database จะปฏิเสธทันที ไม่มีลูกค้า id 9999 ใส่ลงไปไม่ได้
2. ลบ customer ที่ยังมี order ค้างอยู่ = ไม่ได้ (โดย default) — เพราะลบไปแล้ว order จะ “ลอย” ไม่รู้ว่าเป็นของใคร

ข้อ 2 นี่แหละครับที่มี option ให้เลือก เรียกว่า ON DELETE behavior มี 2 แบบหลัก

• ON DELETE RESTRICT (default) — ลบ customer ไม่ได้ ถ้ายังมี order ค้างอยู่ ต้องไปลบ order ก่อน หรือย้าย order ไป customer อื่น ปลอดภัยที่สุด
• ON DELETE CASCADE — ลบ customer = ลบ order ทั้งหมดของ customer คนนั้นทิ้งอัตโนมัติ ใช้กับ relation ที่ “พ่วงกัน” จริงๆ เช่น ลบ user = ลบ session/token ทั้งหมด

สัญญาณเตือน: อย่าใช้ CASCADE กับข้อมูล financial/audit เด็ดขาด ลบลูกค้าครั้งเดียว order 5 ปีย้อนหลังหายหมด สรรพากรเรียกตรวจ เจ๊ง ใช้ “soft delete” แทน (เพิ่มคอลัมน์ deleted_at แล้ว filter ออกตอน query record ยังอยู่ใน database)

MongoDB กับการไม่มี Foreign Key#

ตรงนี้สำคัญสำหรับผู้บริหารที่ทีม IT จะเสนอใช้ NoSQL ครับ — document database อย่าง MongoDB ไม่มี foreign key แบบ native แปลว่า database ไม่บังคับ referential integrity ให้

ตัวอย่าง — MongoDB เก็บ order ที่อ้าง customer_id “abc123” ได้สบาย แม้ customer “abc123” ไม่มีอยู่จริง ลบ customer ทิ้งไป order ที่ชี้มาเป็นซากค้างไว้ query แล้วเจอ “user not found” ทุกครั้ง

วิธีแก้ของ MongoDB — enforce ใน application layer แปลว่า programmer ต้องเขียนโค้ดเช็คเองทุกที่ ก่อน insert order เช็คว่า customer มีอยู่ไหม ก่อนลบ customer เช็คว่ามี order ค้างไหม ปัญหาคือ programmer คนเดียวลืมเช็คที่จุดเดียว = ข้อมูลเสียหายโดยไม่มีใครรู้

นี่คือเหตุผลที่ EP.04 ผมเตือนเรื่องเลือก MongoDB ผิด ถ้าข้อมูลของคุณมี relation จริงๆ (order ↔ customer ↔ product) relational ที่บังคับ FK ให้อัตโนมัติ ปลอดภัยกว่า application layer ที่ programmer ต้องเขียนเช็คเองพันจุดเยอะ

ทีนี้พอเข้าใจ table + key + FK แล้ว เราจะมุดเข้าไปเรื่องที่หนักที่สุดของ EP.06 กัน — normalization

เริ่มต้น: ตารางรกที่ยัดทุกอย่างไว้ที่เดียว#

นี่คือตาราง orders ของร้านค้าออนไลน์ที่ออกแบบโดยมือใหม่ ยัดทุกอย่างไว้ใน 1 ตาราง

ปัญหาที่เห็นด้วยตาเปล่า

1. ชื่อ “พิมพ์” + ที่อยู่ + เบอร์โทรเดียวกัน ซ้ำ 3 ครั้ง (มี 3 order)
2. ถ้าพิมพ์มี 100 order ชื่อกับที่อยู่ซ้ำ 100 รอบ เปลือง storage
3. ถ้าพิมพ์ย้ายบ้าน ต้อง UPDATE 100 row พร้อมกัน ลืม update บางแถว = data inconsistency
4. คอลัมน์ customer_phones มี 2 เบอร์อยู่ใน cell เดียว query “หาลูกค้าที่ใช้เบอร์ 082-yyy” ต้องไปค้นใน text ช้ามาก
5. เปลี่ยนราคา “เสื้อยืด” จาก 350 เป็น 400 ถ้าอัพเดต product_price ทุกแถว → order เก่าราคาเปลี่ยนตาม → บัญชีย้อนหลังพัง

นี่คือตารางที่ยังไม่ผ่าน normalization สักขั้นเดียวครับ มาแก้ทีละขั้นกัน

1NF — ทุก cell มีค่าเดียว ห้ามมีกลุ่มซ้ำ#

กฎของ 1NF (First Normal Form): ทุก cell มีค่าเดียว ไม่มี repeating group

ตัวอย่างที่ผิด — customer_phones = "081-xxx, 082-yyy" cell เดียวมี 2 ค่า

วิธีแก้ — สร้างตารางแยก customer_phones ที่ link กลับมาที่ customer

ตาราง customers (หลัง 1NF)

ตาราง customer_phones (ใหม่)

ตอนนี้ลูกค้า 1 คนมี phone กี่เบอร์ก็ได้ แค่เพิ่ม row ในตาราง customer_phones query “หาลูกค้าที่ใช้เบอร์ 082-yyy” เร็วเพราะค้นใน column ที่เป็น phone โดยตรง

2NF — ทุก non-key column ต้อง depend on PK ทั้งตัว#

กฎของ 2NF (Second Normal Form): ผ่าน 1NF แล้ว + ทุก column ที่ไม่ใช่ key ต้องขึ้นอยู่กับ primary key ทั้งตัว ไม่ใช่แค่บางส่วน กฎนี้มีผลเฉพาะตารางที่ใช้ composite key (PK ที่ประกอบด้วยหลายคอลัมน์)

ตัวอย่างที่ผิด — สมมติเรามีตาราง order_items ที่ใช้ composite key (order_id + product_id)

สังเกตว่า product_name และ product_price ขึ้นอยู่กับ product_id เท่านั้น ไม่เกี่ยวกับ order_id แปลว่า “เสื้อยืด” ราคา 350 ถูกเก็บซ้ำหลายแถว เพราะมีอยู่ใน order หลายใบ

วิธีแก้ — แยก products ออกเป็นตารางใหม่

ตาราง products (ใหม่)

ตาราง order_items (หลัง 2NF)

เปลี่ยนราคาเสื้อยืด — แก้ที่ตาราง products แถวเดียว ทุก order ที่อ้างถึงเห็นราคาใหม่หมด (หรือถ้าอยากเก็บราคา ณ วันสั่ง ก็ copy price มาเก็บใน order_items ตอน insert เป็น design choice)

3NF — non-key column ห้าม depend on non-key column#

กฎของ 3NF (Third Normal Form): ผ่าน 2NF แล้ว + ทุก non-key column ต้องขึ้นกับ PK โดยตรง ไม่ใช่ขึ้นกับ column อื่นที่ไม่ใช่ key

ตัวอย่างที่ผิด — ตาราง customers มีคอลัมน์ city + zipcode

ปัญหาคือ zipcode ไม่ได้ depend on customer.id จริงๆ มัน depend on city (จริงๆ คือ depend on แขวง/ตำบล) ทุกคนในกรุงเทพใจกลางเมืองใช้รหัส 10400 หมด

วิธีแก้ — แยกตาราง cities ออกมา

ตาราง cities (ใหม่)

ตาราง customers (หลัง 3NF)

เปลี่ยน zipcode (ไปรษณีย์เปลี่ยนรหัสเขต) — แก้ที่ตาราง cities แถวเดียว ทุกคนในเขตเห็นรหัสใหม่อัตโนมัติ

หลัง 3NF — เราได้อะไร#

จากตาราง 1 ตารางรกๆ เรา refactor ออกเป็น 5 ตารางที่ link กันด้วย key

• customers — ลูกค้า (id, name, address, city_id)
• customer_phones — เบอร์โทร (customer_id, phone) รองรับหลายเบอร์
• cities — เมือง/เขต (id, name, zipcode)
• products — สินค้า (id, name, price)
• orders + order_items — order และรายการสินค้าใน order

ผลที่ได้

• เปลี่ยนข้อมูลที่จุดเดียว ทุกที่อัพเดตอัตโนมัติ
• ไม่มีข้อมูลซ้ำ storage ลดลง 60-80% สำหรับ table ที่ใหญ่
• ไม่มี data inconsistency แบบ “ที่อยู่เก่า ที่อยู่ใหม่” ที่เปิดบทไว้
• query เฉพาะส่วนได้ตรง เช่น “นับจำนวนลูกค้าในกรุงเทพ” ไป query ตาราง customers + cities โดยไม่ต้องดึง order

นี่คือของขวัญที่ normalization ให้ครับ แต่ทุกของขวัญมีต้นทุน ทีนี้มาดูว่าเมื่อไหร่ “ผิดหลักโดยตั้งใจ” ถึงจะถูก

เมื่อไหร่ denormalize#

1. read-heavy workload — ระบบที่อ่านมากกว่าเขียน 100 เท่า เช่น dashboard ผู้บริหารที่โหลดวันละพันครั้ง ถ้า normalize เต็มที่ ทุก query ต้อง JOIN 5 ตาราง ใช้เวลา 3 วินาที ถ้า denormalize เก็บผลรวมไว้ในตารางเดียว query 50 ms

2. JOIN cost > storage cost — ใน relational, JOIN หลายตารางที่มีล้านแถวกินทรัพยากร CPU มหาศาล storage ราคาถูกลงเรื่อยๆ (Postgres hosting 100 GB ราคาเดือนละไม่กี่ร้อยบาท) บางครั้งเก็บข้อมูลซ้ำสองที่ + อ่านเร็วขึ้น 50 เท่า — คุ้ม

3. eventual consistency รับได้ — ระบบที่ “ข้อมูลช้าไป 5 นาทีไม่ตาย” เช่น analytics, recommendation, reporting ระบบ banking ที่ “ยอดเงินต้องตรง 100% ทุกวินาที” — ห้าม denormalize

ตัวอย่างในวงการ#

• Data warehouse — ระบบเก็บข้อมูลเพื่อทำรายงาน ใช้ denormalized schema (star schema, snowflake schema) ที่ JOIN น้อย query เร็ว ตัวอย่าง Snowflake, BigQuery, Redshift
• OLAP cube — pre-compute ผลลัพธ์ของ dimension ที่ใช้บ่อยไว้ล่วงหน้า ตอบ “ยอดขายแยกตามจังหวัด/เดือน/หมวด” ใน 100 ms แม้มีข้อมูล 10 ปี
• Materialized view — view ที่ pre-compute ผลลัพธ์ + เก็บไว้เป็นตารางจริง ใช้บ่อยใน dashboard
• Caching layer — Redis/Memcached เก็บผลลัพธ์ของ query ที่ใช้บ่อย เป็น denormalization รูปแบบหนึ่ง

Pattern ที่ใช้บ่อย — มี 2 schema คู่ขนาน normalized (OLTP) สำหรับ transaction และ denormalized (OLAP) สำหรับ analytics ETL pipeline copy ข้อมูลจาก OLTP ไป OLAP ทุกชั่วโมง/ทุกคืน ระบบ banking ที่ตัดเงินยังคงใช้ normalized schema 100% ส่วน dashboard ของผู้บริหารใช้ denormalized

เรื่อง read-heavy + analytics + polyglot persistence แบบนี้จะเจาะลึกใน EP.12 — มุม Enterprise: Polyglot Persistence ตอนนี้รู้แค่ว่า “denormalize เป็น tool ไม่ใช่ความผิดพลาด” ก็พอ

ทีนี้พอเข้าใจ schema กับ normalization แล้ว คำถามถัดมาที่หลีกเลี่ยงไม่ได้คือ ระบบ production ที่มีลูกค้าจริงใช้อยู่ เราจะเปลี่ยน schema ยังไงโดยไม่ให้ระบบล่ม?

Migration tool — เครื่องมือพื้นฐาน#

แทนที่จะแก้ schema ตรงๆ ใน production database เราเขียน “migration script” เป็นไฟล์ version-controlled (เก็บใน Git เหมือนโค้ด) แต่ละ script เป็นการเปลี่ยนแปลง schema 1 ครั้ง เช่น “เพิ่มคอลัมน์ phone ในตาราง customers”, “สร้างตาราง addresses ใหม่”, “เปลี่ยน data type ของ price จาก float เป็น decimal”

ตัวอย่างเครื่องมือที่ใช้กันในวงการ

• Flyway (Java ecosystem) — เขียน migration เป็น SQL file ตรงๆ
• Liquibase (Java) — เขียน migration เป็น XML/YAML ที่แปลงเป็น SQL หลายภาษา
• Prisma Migrate (Node.js/TypeScript) — generate migration จาก schema definition
• Alembic (Python, ใช้กับ SQLAlchemy) — เขียน migration เป็น Python script
• Rails ActiveRecord migrations (Ruby) — ต้นแบบของวงการ

ทุกตัวทำเรื่องเดียวกัน track ว่า migration ไหนถูกรันไปแล้วใน database ไหน รัน migration ใหม่อัตโนมัติตอน deploy rollback ได้ถ้าผิดพลาด

Backward-compatible change — หลักทอง#

หัวใจของ migration ที่ไม่ทำระบบล่มคือ ทุกการเปลี่ยน schema ต้องเป็น backward-compatible กับโค้ดเวอร์ชันก่อนหน้า

ตัวอย่างการเปลี่ยน type ของ column — สมมติอยากเปลี่ยน customers.email จาก varchar(100) เป็น varchar(255) (รองรับอีเมลยาวขึ้น)

วิธีผิด — รัน ALTER TABLE customers ALTER COLUMN email TYPE varchar(255) กลางวันที่มีคนใช้ระบบ database lock table ทั้งตาราง 5 นาที ทุก request ระหว่างนั้น timeout ลูกค้าโทรเข้ามาด่า

วิธีถูก — แบ่งเป็น 4 ขั้น

1. Add column ใหม่ — เพิ่ม email_v2 varchar(255) แบบ nullable โค้ดเก่ายังใช้ email เดิมได้ รวดเร็ว ไม่ lock
2. Migrate data — รัน background job copy ข้อมูลจาก email ไป email_v2 ทีละก้อน 1,000 row ครั้ง ใช้เวลานาน แต่ไม่กระทบ production
3. Switch over — deploy โค้ดใหม่ที่อ่าน/เขียน email_v2 โค้ดเก่ายัง deploy อยู่ระหว่างนี้ (rolling deploy)
4. Drop old column — ผ่านไป 1 อาทิตย์ มั่นใจว่าทุกอย่างใช้ email_v2 แล้ว → ลบคอลัมน์ email เก่าทิ้ง

ฟังดูซับซ้อน แต่ผลคือ zero downtime ลูกค้าใช้ระบบไม่หยุดสักวินาทีตลอด migration

Blue-green deployment สำหรับ schema breaking change#

บางการเปลี่ยน schema ทำ backward-compatible ไม่ได้จริงๆ เช่น แยกตารางใหญ่เป็น 5 ตาราง วิธีจัดการคือ blue-green deployment

แนวคิด — มี database 2 ชุด

• Blue = production ปัจจุบัน (schema เก่า)
• Green = สำเนา (schema ใหม่)

flow

1. setup green database พร้อม schema ใหม่
2. setup data sync — ทุก write บน blue → sync ไป green ทันที (ผ่าน CDC: Change Data Capture)
3. รอจนข้อมูล green ตามทัน blue
4. switch traffic จาก blue ไป green ใน 1 วินาที
5. blue กลายเป็น standby — ถ้า green มีปัญหา switch กลับได้

cost สูงกว่า (ต้องรัน 2 databases พร้อมกันช่วงเปลี่ยน) แต่ปลอดภัยที่สุด ใช้กับ migration ที่เสี่ยงสูง หากผิดพลาดเสียหายมหาศาล (เช่น ระบบ banking ระบบ healthcare)