Skip to content

0.4 CHAR(n) vs VARCHAR(n)

นี่คือบทเรียนที่ทำให้ SQL make sense ในที่สุด ถ้าคุณทำ Lesson 0.3 เรื่อง C strings มาแล้ว คุณผ่านครึ่งทางแล้ว

ปัญหา: เราจะจองพื้นที่เท่าไหร่?

Section titled “ปัญหา: เราจะจองพื้นที่เท่าไหร่?”

เวลาเก็บ text ในฐานข้อมูล คอมพิวเตอร์ต้องรู้ว่า “จะจองพื้นที่เท่าไหร่?” มี 2 กลยุทธ์:

เหมือนที่จอดรถที่ทุกช่องมีขนาดเท่ากัน ไม่ว่าจะจอดมอเตอร์ไซค์หรือรถบรรทุก

CHAR(5)
'HI' → เก็บเป็น 'HI ' ← เติม space!
'HELLO' → เก็บเป็น 'HELLO'
  • ✅ อ่านเร็ว (ทุกแถวมีขนาดเท่ากัน)
  • ❌ เปลือง space ถ้า data มีความยาวไม่เท่ากัน
  • 🎯 เหมาะกับ: ค่าที่ยาวเท่ากันเสมอ — รหัสประเทศ ('TH', 'US'), รหัสคงที่

VARCHAR(n) — ขนาดยืดหยุ่น

Section titled “VARCHAR(n) — ขนาดยืดหยุ่น”

เหมือนที่จอดรถที่ช่องยืดหดตามขนาดรถ

VARCHAR(100)
'HI' → เก็บเป็น 'HI' ← 2 chars
'HELLO' → เก็บเป็น 'HELLO' ← 5 chars
  • ✅ ประหยัดพื้นที่
  • ❌ ช้ากว่าเล็กน้อย (ระบบต้องจำว่าแต่ละค่ายาวเท่าไหร่)
  • 🎯 เหมาะกับ: ชื่อ, notes, email, descriptions

กฎง่ายๆ: ถ้าไม่มีเหตุผลจะใช้ CHAR ให้ใช้ VARCHAR

นี่คือที่มาของแนวคิด — SQL ได้ไอเดียจาก C ตรงๆ:

char fixed[5]; // 5 bytes จอง เสมอ
strcpy(fixed, "HI"); // เก็บ H, I, \0, ?, ? (ที่เหลือเป็นขยะ)
char *dynamic = "HI"; // 3 bytes พอดี (H, I, \0)

💡 char fixed[5] ของ C คือ CHAR(5) ของ SQL ทั้งคู่จองพื้นที่ตายตัวไม่ว่าจะใช้จริงเท่าไหร่ SQL แค่รับประกันว่าที่เหลือจะเป็น space (ไม่ใช่ขยะ)