ข้อแลกเปลี่ยนระหว่าง normalization กับ denormalization มีอะไรบ้าง?

Question

IT Interview Practice · Accepted Answer

**Normalization** จัดระเบียบข้อมูลเพื่อให้ข้อเท็จจริงแต่ละอย่างอยู่ในที่เดียวเท่านั้น เป็นการกำจัดความซ้ำซ้อน **Denormalization** จงใจทำสำเนาข้อมูลซ้ำเพื่อให้อ่านได้เร็วขึ้น schema ส่วนใหญ่เริ่มต้นแบบ normalized แล้วค่อย denormalize เฉพาะจุดที่ผลการวัดบ่งชี้ว่าจำเป็น

## Normalization (จนถึง 3NF)

แต่ละตารางอธิบาย entity หนึ่งอย่าง ข้อมูลที่เกี่ยวข้องถูกอ้างอิงด้วย foreign key

```sql
-- Normalized: a customer's city is stored once
customers(id, name, city_id)
cities(id, name)
orders(id, customer_id, total)
```

- **ข้อดี** — ไม่มี update anomaly (แก้ชื่อเมืองในแถวเดียว) พื้นที่จัดเก็บเล็กลง ความถูกต้องผ่าน foreign key
- **ข้อเสีย** — การอ่านต้องใช้ JOIN; รายงานที่แตะหลาย entity อาจต้อง join ห้าตาราง

## Denormalization

```sql
-- Denormalized: city copied onto every order for fast reporting
orders(id, customer_id, city_name, total)
-- + a summary table maintained by the app or triggers
order_daily_totals(day, city_name, total_sales)
```

- **ข้อดี** — join น้อยลง อ่านเร็วขึ้น การรวมยอด (aggregate) ถูกกว่า
- **ข้อเสีย** — ข้อมูลที่ซ้ำต้องถูกรักษาให้ตรงกัน (เขียนมากขึ้น เสี่ยงข้อมูลเพี้ยน) ใช้พื้นที่มากขึ้น และผู้เขียนทุกคนต้องจำไว้ว่าต้องอัปเดตทุกสำเนา

## ตัดสินใจอย่างไร

ตั้งค่าเริ่มต้นเป็น normalized เพื่อความถูกต้อง จง denormalize **เส้นทางการอ่านที่ร้อนแรงเฉพาะจุด** เฉพาะหลังจาก EXPLAIN แสดงว่า join เป็นคอขวด — และควรคง source of truth ไว้แบบ normalized ในขณะที่ดูแลสำเนาที่ได้มา (summary table, materialized cache) ซึ่งคุณสร้างใหม่ได้

## ทำไมจึงสำคัญ

นี่คือข้อแลกเปลี่ยนหลักในการออกแบบ schema: การ normalize มากเกินไปทำให้ dashboard คลานช้า การ denormalize มากเกินไปเพาะพันธุ์ข้อมูลที่ไม่สอดคล้องกันซึ่งมีต้นทุนสูงในการปรับให้ตรงกัน การรู้ *ว่าทำไม* คุณจึงจะทำสำเนาข้อมูล — และจะรักษาสำเนาให้น่าเชื่อถือได้อย่างไร — คือสิ่งที่แยกแยะ schema ที่ขยายได้ออกจาก schema ที่ผุพัง

Normalization (จนถึง 3NF)

Denormalization

ตัดสินใจอย่างไร

ทำไมจึงสำคัญ

คำถามที่เกี่ยวข้อง