Skip to content

📐 Data Structure & Table Design

การออกแบบโครงสร้างตารางที่ดี (Database Schema Design) คือรากฐานของ Application ที่มั่นคง ถ้าออกแบบไม่ดีแต่แรก การแก้ไขภายหลังจะยุ่งยากมาก


🧱 1. Data Types ที่ควรรู้จัก

การเลือกชนิดข้อมูลให้เหมาะสมช่วยประหยัดพื้นที่และทำให้ค้นหาเร็วขึ้น

ตัวเลข (Numeric)

  • INT: จำนวนเต็มปกติ (User ID, จำนวนสินค้า)
  • TINYINT: จำนวนเต็มขนาดเล็ก (-128 ถึง 127) หรือใช้แทน Boolean (0, 1)
  • DECIMAL(Total, Decimals): ทศนิยมที่ต้องการความแม่นยำสูง (ราคา, เงินเดือน) ห้ามใช้ FLOAT เก็บเงินเด็ดขาด!
  • FLOAT/DOUBLE: ทศนิยมวิทยาศาสตร์ (พิกัด GPS, ค่าทางวิทยาศาสตร์)

ข้อความ (String)

  • VARCHAR(n): ข้อความสั้น ปรับความยาวได้ (ชื่อ, อีเมล, รหัสผ่าน) ปกติใช้ 255
  • TEXT: ข้อความยาวไม่จำกัด (เนื้อหาบทความ, คอมเมนต์, JSON)
  • CHAR(n): ข้อความยาวคงที่เสมอ (รหัสไปรษณีย์, รหัสประเทศ TH/US)

วันที่และเวลา (Date & Time)

  • DATETIME: วันที่และเวลา (2024-12-31 23:59:59)
  • DATE: วันที่อย่างเดียว (วันเกิด)
  • TIMESTAMP: คล้าย DATETIME แต่เปลี่ยนตาม Timezone ได้ (Created At, Updated At)

🔑 2. Keys และ Index

Primary Key (PK)

  • คอลัมน์ที่ระบุตัวตนของแถวนั้นๆ อย่างไม่ซ้ำใคร (Unique)
  • ห้ามว่าง (Not Null)
  • ปกติจะใช้ id เป็น PK และตั้งค่าเป็น Auto Increment (เพิ่มค่าเองทีละ 1)

Index

  • สารบัญช่วยค้นหา
  • ควรทำ Index กับคอลัมน์ที่ใช้ในการ WHERE, ORDER BY, หรือ JOIN บ่อยๆ (เช่น email, status, product_category_id)
  • ข้อควรระวัง: Index เยอะทำให้ค้นหาเร็ว แต่ Insert/Update ช้าลง

🧹 3. Database Normalization (ฉบับย่อ)

หลักการลดความซ้ำซ้อนของข้อมูล (Redundancy) เพื่อป้องกันข้อมูลขัดแย้งกัน

กฎข้อที่ 1 (1NF): ค่าในช่องต้องเป็นค่าเดียว

❌ เก็บเบอร์โทร: 081-111-1111, 082-222-2222 ในช่องเดียว ✅ แยกเป็นแถวใหม่ หรือสร้างตาราง user_phones แยกต่างหาก

กฎข้อที่ 2 (2NF) & 3 (3NF): แยกตารางตามเรื่อง

❌ ตาราง Orders เก็บ customer_name, customer_address ซ้ำๆ ทุก order ✅ สร้างตาราง Customers เก็บชื่อที่อยู่ แล้วในตาราง Orders เก็บแค่ customer_id


💡 4. Best Practices ในการออกแบบ

  1. ตั้งชื่อเป็นภาษาอังกฤษเสมอ: users (พหูพจน์), first_name (snake_case)
  2. มี id เป็น PK เสมอ: แม้จะมีรหัสบัตรประชาชน แต่การใช้ Running ID (1, 2, 3...) เป็น PK ภายในระบบจะจัดการง่ายกว่า
  3. เก็บวันที่ให้ถูกต้อง: อย่าเก็บวันที่เป็น String ('01/01/2024') ให้ใช้ DATE หรือ DATETIME เสมอ เพื่อให้ Sort และ Filter ได้
  4. Soft Delete: ถ้าข้อมูลสำคัญ อย่าลบจริง (Hard Delete) ให้เพิ่มคอลัมน์ deleted_at แทน เพื่อซ่อนข้อมูล (Laravel มีฟีเจอร์นี้ให้)