ฐานข้อมูลคืออะไร คู่มือสำหรับผู้สร้างแอป
ฐานข้อมูลคือที่เก็บข้อมูลที่จัดระเบียบไว้ ซึ่งแอปบันทึกและอ่านกลับมาได้ ไม่ว่าจะเป็นผู้ใช้ ออเดอร์ การจอง หรือข้อความ ข้อมูลในฐานข้อมูลจะยังอยู่หลังจากรีเฟรชหรือรีสตาร์ต และทุกคนที่ใช้แอปจะเห็นเรคคอร์ดชุดเดียวกัน ฐานข้อมูลส่วนใหญ่จัดข้อมูลเป็นตาราง คล้ายชีตในสเปรดชีต แต่มีกฎที่เข้มงวดคอยรักษาความสอดคล้องของข้อมูล
ทำไมเรื่องนี้สำคัญเมื่อสร้างด้วย AI
สิ่งที่ทำให้คนที่สร้างด้วย AI แปลกใจที่สุดคือแอปที่ดูเสร็จแล้วแต่กลับลืมทุกอย่าง คุณเพิ่มลูกค้า รีเฟรชหน้า แล้วข้อมูลหายไป ซึ่งมักหมายความว่าแอปเก็บข้อมูลไว้ในหน่วยความจำของเบราว์เซอร์ ไม่ใช่ในฐานข้อมูล
ฐานข้อมูลยังเป็นที่ที่การตัดสินใจสำคัญหลายอย่างอยู่ ไม่ว่าคุณจะตระหนักหรือไม่:
- สิ่งที่คุณบันทึก ถ้าคุณไม่เก็บสถานะของการจอง คุณก็แสดงไม่ได้ว่าการจองใดถูกยกเลิก
- สิ่งที่เชื่อมโยงกัน ลูกค้าคนหนึ่งจองได้หลายครั้ง หรือการจองหนึ่งครั้งมีหลายบริการได้หรือไม่ เรื่องนี้กำหนดโครงสร้างของแอปทั้งหมด
- ใครเห็นอะไรได้บ้าง ปัญหาความเป็นส่วนตัวส่วนใหญ่เกี่ยวกับว่าผู้ใช้อ่านเรคคอร์ดใดได้บ้าง
คุณไม่จำเป็นต้องออกแบบฐานข้อมูลเอง แต่การเข้าใจพื้นฐานจะช่วยให้คุณอธิบายข้อมูลของคุณได้ชัดเจนและจับปัญหาได้ตั้งแต่เนิ่น ๆ
ตัวอย่างใกล้ตัว
ลองนึกภาพตู้เอกสารที่เป็นระเบียบในสำนักงานเล็ก ๆ
ลิ้นชักแต่ละอันเก็บสิ่งของชนิดเดียว: ลิ้นชักหนึ่งสำหรับลูกค้า อีกอันสำหรับนัดหมาย และอีกอันสำหรับใบแจ้งหนี้ ภายในแต่ละลิ้นชัก แฟ้มทุกแฟ้มมีรูปแบบเดียวกันและกรอกช่องเหมือนกัน แต่ละแฟ้มมีเลขอ้างอิงที่ไม่ซ้ำกัน และเมื่อใบแจ้งหนี้เป็นของลูกค้าคนใด แฟ้มใบแจ้งหนี้ก็จดเลขลูกค้าคนนั้นไว้ แทนที่จะถ่ายสำเนาแฟ้มทั้งหมดของเขามาใส่
นั่นคือฐานข้อมูลเชิงความสัมพันธ์ ลิ้นชักคือตาราง แฟ้มคือแถว ช่องในแฟ้มคือคอลัมน์ เลขอ้างอิงคือคีย์หลัก (primary key) และบันทึกที่ชี้ไปยังแฟ้มอื่นคือคีย์นอก (foreign key) ผู้จัดการสำนักงานที่ดีจะบังคับใช้กฎ เช่น ห้ามมีนัดหมายที่ไม่มีวันที่ ห้ามมีลูกค้าสองคนที่เลขเดียวกัน เช่นเดียวกับฐานข้อมูล
ตัวอย่างจริง: แอปจองคิวร้านทำผม
สมมติว่าคุณขอให้ AI สร้างเว็บจองคิวให้ร้านทำผมแห่งหนึ่ง ฐานข้อมูลที่เหมาะสมจะมีสี่ตาราง
services
| id | name | duration_minutes | price |
|---|---|---|---|
| 1 | ตัดผม | 45 | 40.00 |
| 2 | ทำสี | 90 | 95.00 |
staff
| id | name | |
|---|---|---|
| 1 | สารา | sara@example.com |
| 2 | โอมาร์ | omar@example.com |
customers
| id | name | phone | |
|---|---|---|---|
| 101 | Lena Park | lena@example.com | 555-0100 |
bookings
| id | customer_id | service_id | staff_id | starts_at | status |
|---|---|---|---|---|---|
| 5001 | 101 | 1 | 2 | 2026-10-03 14:00 | confirmed |
ดูที่ตาราง bookings มันไม่ได้คัดลอกชื่อและเบอร์โทรของ Lena ไปใส่ในทุกการจอง แต่เก็บ customer_id = 101 ถ้า Lena เปลี่ยนเบอร์โทร ข้อมูลจะเปลี่ยนในที่เดียว และทุกการจองจะแสดงเบอร์ใหม่ นี่คือแนวคิดหลักของฐานข้อมูลเชิงความสัมพันธ์ คือเก็บข้อเท็จจริงแต่ละอย่างครั้งเดียว แล้วเชื่อมโยงไปยังข้อเท็จจริงนั้น
โครงสร้างเดียวกันนี้ตอบคำถามที่มีประโยชน์ได้ด้วย:
- “วันศุกร์นี้โอมาร์ว่างช่วงไหนบ้าง” ดูการจองของโอมาร์ในวันนั้น
- “เดือนนี้บริการทำสีทำรายได้เท่าไร” เชื่อมตาราง bookings กับ services แล้วรวมราคา
- “ลูกค้าคนไหนไม่ได้จองมาเกิน 90 วันแล้ว” เปรียบเทียบรายชื่อลูกค้ากับการจองล่าสุดของแต่ละคน
คำศัพท์ที่ควรรู้
| คำศัพท์ | ความหมาย |
|---|---|
| ตาราง (Table) | กลุ่มของเรคคอร์ดประเภทเดียว เช่น ลูกค้าหรือการจอง |
| แถว (Row / record) | หนึ่งรายการในตาราง เช่น ลูกค้าหนึ่งคน การจองหนึ่งครั้ง |
| คอลัมน์ (Column / field) | ข้อมูลหนึ่งชนิดที่ทุกแถวมี เช่น อีเมลหรือราคา |
| คีย์หลัก (Primary key) | ID ที่ไม่ซ้ำสำหรับแต่ละแถว มักเป็นตัวเลขหรือสตริงสุ่ม |
| คีย์นอก (Foreign key) | คอลัมน์ที่ชี้ไปยังแถวในตารางอื่น เช่น customer_id ในตาราง bookings |
| Schema | การออกแบบโดยรวม: มีตารางอะไรบ้าง คอลัมน์ของแต่ละตาราง และการเชื่อมโยงกัน |
| Query | คำขออ่านหรือเปลี่ยนแปลงข้อมูล เช่น “การจองทั้งหมดของพรุ่งนี้” |
| SQL | Structured Query Language ซึ่งเป็นภาษามาตรฐานสำหรับ query ฐานข้อมูลเชิงความสัมพันธ์ |
| Migration | การเปลี่ยนแปลง schema ที่บันทึกไว้และทำซ้ำได้ เช่น การเพิ่มคอลัมน์ |
| Index | โครงสร้างสำหรับค้นหาที่ทำให้การค้นหาในคอลัมน์หนึ่งเร็วขึ้น เหมือนดัชนีท้ายหนังสือ |
| CRUD | Create, Read, Update, Delete คือสี่อย่างพื้นฐานที่แอปทำกับข้อมูล |
| Backup | สำเนาของข้อมูลที่คุณกู้คืนได้เมื่อมีอะไรผิดพลาด |
ประเภทของฐานข้อมูล
| ประเภท | วิธีเก็บข้อมูล | ตัวอย่าง | เหมาะกับ |
|---|---|---|---|
| Relational (SQL) | ตารางที่มีคอลัมน์คงที่และการเชื่อมโยงระหว่างตาราง | Postgres, MySQL, SQLite | แอปธุรกิจส่วนใหญ่: การจอง ร้านค้า CRM SaaS |
| Document (NoSQL) | เอกสารที่ยืดหยุ่นคล้าย JSON | MongoDB, Firestore | ข้อมูลที่รูปร่างแตกต่างกันมากในแต่ละเรคคอร์ด |
| Key-value | ค่าที่เก็บไว้ภายใต้คีย์ | Redis | แคช และข้อมูลระยะสั้น เช่น session |
สำหรับสิ่งที่ผู้ก่อตั้งหรือธุรกิจขนาดเล็กสร้างเป็นอย่างแรก ฐานข้อมูลเชิงความสัมพันธ์คือค่าเริ่มต้นที่ปลอดภัยที่สุด
ฐานข้อมูลอยู่ตรงไหนในแอปของคุณ
ผู้เข้าชมไม่ได้คุยกับฐานข้อมูลโดยตรง หน้าเว็บในเบราว์เซอร์ของเขา (frontend) จะขอข้อมูลจากเซิร์ฟเวอร์ของคุณ (backend) ซึ่งโดยทั่วไปผ่าน API เซิร์ฟเวอร์ตรวจสอบว่าใครเป็นคนขอและมีสิทธิ์หรือไม่ จากนั้น query ฐานข้อมูลและส่งกลับเฉพาะสิ่งที่คนนั้นควรเห็น
ขั้นตอนตรงกลางนี้สำคัญมาก ถ้าเบราว์เซอร์สามารถ query ฐานข้อมูลโดยตรงด้วยสิทธิ์เต็ม ใครก็ได้จะเปิดเครื่องมือนักพัฒนาและอ่านทุกอย่างได้
ความเข้าใจผิดและข้อผิดพลาดที่พบบ่อย
- เก็บข้อมูลไว้เฉพาะในเบราว์เซอร์ พื้นที่เก็บข้อมูลของเบราว์เซอร์ (เช่น localStorage) อยู่บนอุปกรณ์และเบราว์เซอร์เครื่องเดียว ใช้จำตัวกรองได้ แต่ไม่เหมาะกับออเดอร์
- ยัดทุกอย่างลงตารางเดียว ตาราง “bookings” เดียวที่คัดลอกชื่อ เบอร์โทร และราคาบริการของลูกค้าไปไว้ในทุกแถว จะไม่ตรงกันอย่างรวดเร็ว
- เก็บรหัสผ่านเป็นข้อความธรรมดา รหัสผ่านควรถูก hash ไม่ควรเก็บแบบอ่านได้ ดู การยืนยันตัวตนคืออะไร
- ไม่มีกฎสำหรับข้อมูล หากไม่มีฟิลด์บังคับและกฎความไม่ซ้ำ คุณจะได้การจองที่ไม่มีวันที่และลูกค้าซ้ำกัน
- ลืมเรื่องการลบ ตัดสินใจว่าเมื่อลบลูกค้าแล้วจะลบการจองของเขาด้วย เก็บไว้ หรือห้ามลบ
- ใช้ข้อมูลจริงในการทดลอง ทดสอบการเปลี่ยนแปลงที่เสี่ยงในที่ปลอดภัยก่อน และเก็บ backup ไว้เสมอ
- ใช้สเปรดชีตเป็นฐานข้อมูลไปตลอด สเปรดชีตเหมาะกับการเริ่มต้น แต่จะรับมือกับผู้ใช้จำนวนมากที่ทำงานพร้อมกันและสิทธิ์การใช้งานได้ยาก ดู วิธีเปลี่ยนสเปรดชีตให้เป็นแอป
สิ่งที่ควรขอจากตัวสร้างแอปด้วย AI
- “บันทึกสิ่งนี้ในฐานข้อมูล ไม่ใช่ในเบราว์เซอร์ และบอกฉันว่าคุณจะสร้างตารางใดบ้าง”
- “แสดง schema ให้ฉันดูเป็นตารางง่าย ๆ: แต่ละตาราง คอลัมน์ และการเชื่อมโยงกัน”
- “ลูกค้าหนึ่งคนจองได้หลายครั้ง การจองแต่ละครั้งมีบริการหนึ่งอย่างและพนักงานหนึ่งคนเท่านั้น”
- “ทำให้อีเมลของลูกค้าเป็นฟิลด์ที่จำเป็นและไม่ซ้ำกัน”
- “หยุดไม่ให้การจองสองครั้งของพนักงานคนเดียวกันทับซ้อนกัน”
- “มีเพียงเจ้าของที่ล็อกอินเท่านั้นที่อ่านการจองทั้งหมดได้ ลูกค้าเห็นได้เฉพาะของตัวเอง บังคับใช้กฎนี้บนเซิร์ฟเวอร์”
- “เมื่อฉันลบบริการ อย่าลบการจองในอดีต ให้ทำเครื่องหมายบริการว่าไม่ใช้งานแทน”
ฐานข้อมูลใน Mythex
เมื่อแอปของคุณต้องบันทึกข้อมูล Mythex จะเพิ่มฐานข้อมูล Postgres เฉพาะให้กับโปรเจกต์ คุณสามารถขอในแชตได้ (“บันทึกรายชื่อผู้สนใจลงในฐานข้อมูล”) หรือใช้คำสั่ง /database รายละเอียดการเชื่อมต่อจะถูกส่งให้แอปโดยอัตโนมัติ และเอเจนต์จะสร้างตารางให้ ฐานข้อมูลจะหลับเมื่อไม่มีการใช้งานห้านาที และตื่นเมื่อมีคำขอถัดไป การใช้งานของแอปที่เผยแพร่แล้วจะถูกคิดตามเวลาที่ฐานข้อมูลตื่นอยู่ จากยอดเครดิตเดียวกับการสร้างแอป ใช้ได้ทั้งในแพ็กเกจ Free และ Pro เอกสารฐานข้อมูล อธิบายรายละเอียดไว้ และเทมเพลตแอป มีจุดเริ่มต้นที่ขับเคลื่อนด้วยข้อมูล
คำถาม
ฐานข้อมูลคืออะไรแบบง่าย ๆ
ฐานข้อมูลคือที่เก็บข้อมูลที่จัดระเบียบไว้ ซึ่งแอปสามารถบันทึกและอ่านได้ เช่น ผู้ใช้ ออเดอร์ หรือการจอง ต่างจากข้อมูลที่เก็บไว้เฉพาะในแท็บเบราว์เซอร์ ข้อมูลในฐานข้อมูลจะยังอยู่หลังรีเฟรช รีสตาร์ต หรือเมื่อมีคนเปิดแอปจากอุปกรณ์อื่น
สเปรดชีตคือฐานข้อมูลหรือไม่
สเปรดชีตเก็บข้อมูลประเภทเดียวกันได้ แต่ไม่ได้ออกแบบมาสำหรับแอป ฐานข้อมูลจริงบังคับใช้กฎว่าแต่ละคอลัมน์เก็บอะไร เชื่อมตารางเข้าด้วยกันอย่างน่าเชื่อถือ รองรับผู้คนจำนวนมากที่เขียนข้อมูลพร้อมกัน และควบคุมว่าใครอ่านอะไรได้บ้าง
ความแตกต่างระหว่างฐานข้อมูล SQL กับ NoSQL คืออะไร
ฐานข้อมูล SQL (relational) เช่น Postgres และ MySQL เก็บข้อมูลในตารางที่มีคอลัมน์และความสัมพันธ์ที่กำหนดไว้ ส่วนฐานข้อมูล NoSQL เช่น MongoDB เก็บเอกสารที่ยืดหยุ่นกว่า แอปธุรกิจส่วนใหญ่ เช่น ระบบจอง CRM และร้านค้า เหมาะกับโมเดลแบบ relational
แอปของฉันต้องใช้ฐานข้อมูลหรือไม่
ถ้าแอปต้องจำสิ่งที่ผู้คนป้อนเข้ามา เช่น การลงทะเบียน ออเดอร์ ข้อความ หรือการตั้งค่า และต้องแสดงภายหลังหรือให้คนอื่นเห็น ก็ต้องใช้ แต่เว็บข้อมูลอย่างเดียวที่ไม่มีฟอร์มบันทึกข้อมูล โดยทั่วไปไม่จำเป็นต้องใช้