แนวทางการออกแบบ Database สำหรับการทำ No-Code / Low-Code / Vibe Coding ฉบับเข้าใจง่าย

สมัยนี้การจะใช้เครื่องมือ Vibe coding, No-code หรือ Low-code เพื่อสร้างแอป ฯ กลายเป็นเรื่องง่ายสำหรับทุกคน แต่สิ่งหนึ่งที่ยังคงเป็นความท้าทาย ไม่ใช่การสร้าง UI สวย ๆ แต่เป็นการเก็บข้อมูลให้มีประสิทธิภาพและเหมาะสมกับธุรกิจ ที่แม้แต่ Generative AI ส่วนใหญ่มักแนะนำไม่ค่อยได้ โดยในบทความนี้จะพาทุกคนมาเรียนรู้หลักการการออกแบบ Database ซึ่งเป็นหัวใจสำคัญในการเก็บข้อมูลที่มีประสิทธิภาพ ทำให้ลดปัญหาที่น่าปวดหัวต่าง ๆ มากมาย

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

สนใจอบรม AppSheet ในบริษัท อ่านรายละเอียด AppSheet In-house training เพิ่มเติมที่นี่

ทำไมการออกแบบ Database ถึงสำคัญกับการสร้าง Application

การออกแบบ Database ที่ดีเปรียบเสมือนการวางรากฐานบ้าน หากรากฐานแข็งแรง บ้านจะอยู่ได้นาน แต่หากรากฐานผิดพลาด การแก้ไขในภายหลังจะยุ่งยากและเสียค่าใช้จ่ายสูง

ตัวอย่างปัญหาที่อาจจะเกิดขึ้นหากไม่มีการออกแบบ Database ที่ดี

• ไม่รองรับการบันทึกข้อมูลบางรูปแบบ:
  ร้านค้าออนไลน์มีระบบบันทึกเฉพาะเบอร์โทรไทย 10 หลัก (+66) XX-XXX-XXXX)
  ในอนาคตเมื่อมีลูกค้าต่างชาติอย่างเช่น ลูกค้าฮ่องกง (+852) X-XXX-XXXX (เบอร์โทรศัพท์ฮ่องกง) จะทำให้ไม่สามารถบันทึกข้อมูลได้
• ข้อมูลไม่สอดคล้อง:
  ในระบบบันทึกข้อมูลคุณสมชาย สมิทธิ์ ซึ่งเปลี่ยนชื่อเป็น สมชาย จริงใจ หลังแต่งงาน ลูกค้าคนเดียวกัน แต่ระบบบันทึกเป็นลูกค้า 2 คน แยกประวัติการซื้อ เพราะลูกค้าเปลี่ยนชื่อ ระบบเลยเห็นเป็นคนละคน
• ข้อมูลซ้ำซ้อน:
  การบันทึกข้อมูลเรื่องเพศชายมีหลายรูปแบบทั้ง “Male”, “ชาย”, “M” ทำให้เกิดความสับสนตอนวิเคราะห์ข้อมูล

เรียนรู้ผ่านตัวอย่าง Application นัดหมายประเมินสภาพรถมือสอง

ยกตัวอย่างธุรกิจ ขายรถมือสอง ที่ต้องการทำ Application จองคิวประเมินสภาพรถก่อนรับซื้อรถมือสองมาฝากขาย

โดยในระบบงานเดิม อาจจะมีการใช้กระดาษ หรือ Excel ในการบันทึกการจองคิวอยู่แล้ว แต่ธุรกิจต้องการ Application เพื่อทำให้สะดวกต่อลูกค้าในการจองคิวตรวจสอบ และพนักงานจะได้ง่ายต่อการจัดคิว เตรียมช่างอีกด้วย

เพื่อให้ระบบทำงานได้ ตัวระบบควรมีการบันทึกข้อมูลประวัติการจองตรวจสภาพรถประมาณนี้เช่น

นาย Peter Oun เบอร์โทร 080-929-9999 ลูกค้าบุคคลทั่วไป
จะนำรถทะเบียน กต.1150 ยี่ห้อ Honda รุ่น Civic 
มาประเมิน ในวันที่ 12/08/2025 เวลา 12:00-13:00
โดยต้องการ
- บริการประเมินสภาพรถเบื้องต้น
- บริการตรวจสอบประวัติการใช้รถ

ข้อมูลข้างต้น ทำให้เกิดการใช้ประโยชน์ได้ดังนี้

• พนักงานตรวจสอบได้ว่า วันเวลาดังกล่าวพร้อมสำหรับการให้บริการมั้ย ผ่านการตรวจสอบคิวช่าง และสถานที่ ก่อนคอนเฟิร์มนัดหมายกับลูกค้า และช่างต่อไป
• ผู้บริหารสามารถเอาข้อมูลมาวิเคราะห์ได้ว่า รถรุ่นไหน ยี่ห้อไหน มีคนเอามาปล่อยขายเป็นรถมือสองมากที่สุด หรือบริการไหนที่ลูกค้าสนใจเป็นต้น

ตัวอย่าง Application จองคิวประเมินรถมือสองที่ทำด้วย Claude

หลักการบันทึกข้อมูลที่ดี: Foundation ของการออกแบบ Database

หลักการบันทึกข้อมูลที่ดี ไม่ว่าคุณจะเก็บข้อมูลบน Google Sheet หรือ Database หรือบนกระดาษ อันนี้คือหลักการครอบจักรวาลที่คุณควรรู้ การบันทึกข้อมูลที่ดีคือ การบันทึก Event ที่เกิดขึ้น ณ ตอนนั้น ๆ ด้วย Format ที่คอมพิวเตอร์เข้าใจได้

หลักการสำคัญที่สุดในการออกแบบ Database คือ การบันทึก Event ที่เกิดขึ้น ณ ตอนนั้น ๆ ด้วย Format ที่คอมพิวเตอร์เข้าใจได้

ซึ่งทำให้แบ่งได้ออกมาเป็นสองส่วน คือจะบันทึกอะไร และบันทึกด้วยรูปแบบไหนดังนี้

การบันทึก Event ที่เกิดขึ้น และใช้ข้อมูลอื่น ๆ มาอ้างอิง Event นั้น

หลายครั้งเราอาจจะคิดว่าต้องบันทึกข้อมูลเป็นส่วน ๆ เช่นข้อมูลลูกค้า ข้อมูลสินค้า จนลืมข้อมูลอื่น ๆ ที่สำคัญ ทางเราเลยให้มองว่าสิ่งที่เราทำคือต้องการจะบันทึก Event หรือเหตุการณ์ที่เกิดขึ้น ณ ตอนนั้น จะทำให้เห็นภาพชัดเจนมากกว่าว่าต้องบันทึกอะไรบ้าง เช่น

เมื่อวันที่ 01/08/2025 เวลา 10:30
- รถทะเบียน กต.1150 ยี่ห้อ Honda รุ่น Civic
- ของลูกค้า นาย Peter Oun เบอร์โทร 080-929-9999 ลูกค้าบุคคลทั่วไป
- จองบริการประเมินรถ 2 อย่าง: 
  บริการประเมินสภาพรถเบื้องต้น
  บริการตรวจสอบประวัติการใช้รถ
- สถานะ: รอการยืนยัน
- จองตรวจสภาพรถมือสอง วันที่ 12/08/2025 เวลา 12:00-13:00

จะสังเกตเห็นว่าเริ่มแรกเราแค่บันทึกเหตุการณ์ เมื่อวันที่ 01/08/2025 เวลา 10:30 แล้วค่อยเอาข้อมูลอื่น ๆ มาเติมเพื่ออธิบายว่าตอนนั้นมีอะไรเกิดขึ้นบ้าง

ถ้าหากเราลองเขียนกลุ่มของข้อมูลอย่างง่ายจะเขียนได้ในรูปแบบนี้ โดยเส้นที่ต่อแสดงถึงเรื่องที่เราจะหยิบมาอธิบายเหตุการณ์นั้น ๆ

Machine Readable Format: รูปแบบที่คอมพิวเตอร์เข้าใจ

ข้อมูลที่ดีต้องเก็บด้วย Format ที่คอมพิวเตอร์เข้าใจได้ง่ายเรียกว่า Machine Readable Format ซึ่งอาจจะมีหลากหลายรูปแบบ แต่สำหรับการเก็บข้อมูลโดยทั่ว ๆ ไปเราเก็บข้อมูลในรูปแบบ Tabular format (Table, ตารางเก็บข้อมูล เหมือนที่เราใช้ใน Excel) อ่านรายละเอียดเพิ่มเติมเกี่ยวกับ Machine Readable Format ที่นี่

ซึ่งโดยปกติหากเก็บข้อมูลใน Database ประเภท SQL (Tabular) ระบบจะบังคับให้เก็บข้อมูลตาม Format ที่ดีอยู่แล้ว แต่ในขั้นตอนการออกแบบ หรืออยากประยุกต์ใช้ Concept นี้ในการเก็บข้อมูลบน Google Sheet จะมีรูปแบบดังนี้

รูปแบบที่เหมาะสม (โดยอ้างอิงจาก Google Sheet)

• 1 Sheet ของ Google Sheet มองเป็น 1 Table ซึ่งในข้อมูลจริง อาจจะมีหลาย Table
• แถวแรกกำหนดให้เป็น หัวข้อของเรื่องที่ต้องการจะบันทึก (ใช้แถวแรกเท่านั้น) โดยใช้ตัวภาษาอังกฤษพิมเล็ก และ underscore แทนการเว้นวรรค: เพื่อให้ง่ายต่อการทำงานต่อไป
• แถวต่อมาที่เหลือ จะเป็นข้อมูลที่ต้องการบันทึก บันทึกเป็นแถวยาวลงมา
• ไม่อยู่ในรูปของตารางไขว้ หรือ Pivot table ที่อ่านได้หลายทาง
• 1 ช่องเก็บข้อมูล 1 อย่าง: ไม่ใส่หลายข้อมูลในช่องเดียว เพราะจะแยกต่อการนำข้อมูลไปวิเคราะห์หรือแก้ไขภายหลัง
• ไม่มีการจัด Format หรือ Merge cell หรือใส่ข้อมูลอื่น ที่ไม่เกี่ยวกับการบันทึกข้อมูล

ตัวอย่างรูปแบบการใช้ไฟล์ Google Sheet ที่ไม่แนะนำ

• มี Header หรือหัวข้อมากกว่า 1 ชั้น
• มีการ Merge cell
• เป็นตารางไขว้อ่านได้สองทาง
• ในหนึ่งช่องบันทึกข้อมูลหลายอย่าง

ขั้นตอนการออกแบบ Database: จากแนวคิดสู่การปฏิบัติ

ในพาร์ทนี้จะเป็นการสาธิตการออกแบบ Database ซึ่งหัวใจสำคัญคือการวิเคราะห์ความสัมพันธ์ของข้อมูลแต่ละอันว่าเป็นอย่างไร และพยายามออกแบบเพื่อลดปัญหาที่อาจจะเกิดขึ้นในอนาคต

ขั้นตอนที่ 1: วิเคราะห์ความสัมพันธ์ของข้อมูล

เริ่มต้นด้วยการระบุเหตุการณ์ที่ต้องการบันทึกและข้อมูลที่เกี่ยวข้อง

กรณีศึกษา: ระบบจองประเมินรถมือสอง

เหตุการณ์หลัก: ลูกค้าจองคิวประเมินรถ

ข้อมูลที่เกี่ยวข้อง:

• ข้อมูลลูกค้า: ชื่อ-สกุล, เบอร์โทร, ประเภทลูกค้า
• ข้อมูลรถ: ทะเบียน, ยี่ห้อ, รุ่น, ปี
• ข้อมูลการจอง: วันที่-เวลา, สถานะ
• ข้อมูลบริการ: บริการ, หมายเหตุบริการนั้น ๆ

ขั้นตอนที่ 2: สร้าง Table หลักและกำหนดหัวข้อของข้อมูล (Fields)

ในขั้นตอนนี้ เราจะลองลิสต์ข้อมูลที่น่าจะต้องบันทึกในระบบอย่างง่ายก่อน (ในตัวอย่างจะลิสต์ขึ้นมาคร่าว ๆ จึงออกจะไม่ได้มีข้อมูลครบถ้วนเท่าของที่ใช้งานจริง ๆ) ในรูปแบบ Table ดังภาพ

โดยแถบบนคือ ชื่อ Table และแต่ละ Column คือ Field ข้อมูล พร้อมตัวอย่างข้อมูลจริง

Table APPOINTMENTS

Field ข้อมูลมีดังนี้

ข้อมูลบริการ การตรวจสอบรถ ของรถหนึ่งคันมีได้หลายอัน ซึ่งหากบันทึกข้อมูลบริการหลาย ๆ อันในช่องเดียวจะไม่ใช่แนวทางที่ดี เราจะหยิบเรื่องนี้มาทำในขั้นตอนถัดไป

ข้อผิดพลาดที่พบบ่อยในการกำหนด Field ข้อมูลที่ต้องการจะบันทึก

• เก็บข้อมูลแค่บางส่วน ไม่ได้นึกถึงการใช้งานในอนาคต:
  การเก็บข้อมูลเท่าที่ใช้ เช่นเก็บชื่อเล่น แทนชื่อจริง เก็บข้อมูลปี แทนที่จะเก็บวันและเวลา ทำให้มีปัญหาตอนจะวิเคราะห์หรือใช้ข้อมูลในอนาคต
  • ตัวอย่างการเก็บข้อมูลเรื่องวันที่สร้างรายการแค่วันเดือนปี โดยไม่เก็บเวลา หากเก็บแค่วัน เดือน ปี อย่างเดียว ในอนาคตหากอยากทำการวิเคราะห์เรื่องเวลา อาจจะทำไม่ได้เพราะเก็บข้อมูลมาแค่นั้น
  • ตัวอย่างการเก็บข้อมูลชื่อเล่นแทนที่จะเก็บชื่อ นามสกุล ซึ่งอาจจะเกิดปัญหาหากมีคนชื่อเล่นซ้ำกัน
    
• รวมข้อมูลหลายอย่างในช่องเดียว
  การรวมข้อมูลบางอย่างเก็บในช่องเดียวทำให้ภายหลังยากต่อการนำไปใช้ต่อ
  • ตัวอย่างการเก็บ ชื่อ และนามสกุล ควรเก็บแยกช่องกัน เพราะอาจจะมีการใช้เพื่อกรองหาคนที่เป็นญาติกันเป็นต้น
• เก็บข้อมูลในรูปแบบข้อมูลดิบที่ละเอียดที่สุด
  อย่างข้อมูลเรื่องวันที่ เราควรจะเก็บเป็นรูปแบบที่เป็นข้อมูลดิบ เช่นวันเวลาจะเก็บในรูปแบบ UTC: 2025-09-28T01:38:19Z หรือ 1759023499 แทนที่จะเก็บเป็น 28/09/2025 เพราะบางท้องที่ใช้ Format แบบ dd/mm/yyyy (England) แต่บางที่ใช้ mm/dd/yyyy (USA) ทำให้ต้องมีการเขียนกำกับอีก

ขั้นตอนที่ 3: การกำหนด Primary Key ให้กับ Table

เพราะข้อมูลแต่ละแถว มีโอกาสซ้ำกันได้เสมอ ทำให้ในอนาคตเกิดความยากลำบากในการอ้างอิง เราเลยต้องมีรหัสบางอย่าง เพื่อเป็นระบุตัวตนเสมอ โดยสิ่งที่อ้างอิงข้อมูลนั้นจะเรียกว่า Primary Key

Primary Key เปรียบเสมือนรหัสประจำตัวของแต่ละ Record ทำให้เราสามารถอ้างอิงข้อมูลได้แม้ข้อมูลอื่นเปลี่ยนแปลง ตัวอย่างเช่นหากเราเก็บข้อมูลพนักงาน ชื่ออาจจะเปลี่ยนได้ อีเมลอาจจะเปลี่ยนได้ แต่รหัสพนักงานจะไม่เปลี่ยน

Primary Key ส่วนใหญ่จะเป็นการสร้างรหัสใหม่ขึ้นมาในระบบ โดยอาจจะเป็นรหัสที่สุ่มขึ้น (เลขแปลก ๆ) หรือ เป็นตัวเลขที่นับขึ้นไปเรื่อย ๆ 1,2,3,4 หรือแม้แต่เอารหัสที่มีอยู่แล้วมาใช้เลย เช่นรหัสบัตรประชาชน รหัสพนักงาน

Primary Key ต้องไม่ซ้ำกัน และมีค่าเสมอสำหรับทุก ๆ Record

โดยในที่นี้เราจะเพิ่ม Primary Key ของ Table ของเรา คือรหัสการจอง

ขั้นตอนที่ 4: ลดความซ้ำซ้อนของข้อมูล ด้วยการแยก Table ย่อย

เมื่อลองบันทึกข้อมูลไปเยอะขึ้นมีโอกาสที่ข้อมูลบางอย่างอาจจะเกิดการเปลี่ยนแปลง ทำให้ข้อมูลที่หมายถึงสิ่งเดียวกัน หน้าตาไม่เหมือนกันได้

• กรณีที่ นาย Peter Oun เอารถมาแจ้งประเมินหลาย ๆ ครั้ง ๆ
• อาจจะเกิดกรณีนาย Peter Oun เปลี่ยนชื่อเป็น Peat Oun ทำให้เมื่ออ่านข้อมูล หรือเอาข้อมูลมาวิเคราะห์แล้วจะเห็นเป็นคนสองคน ซึ่งไม่ถูกต้อง ต้องแก้ให้เหมือนกันทั้งระบบ โดยการเปลี่ยนชื่อ Peter Oun เป็น Peat Oun ด้วย ซึ่งหากข้อมูลมีเป็นล้าน ๆ แถว อาจจะต้องใช้เวลานานกว่าจะเปลี่ยนแปลงข้อมูลครบ (หรืออย่างกรณีเปลี่ยนเบอร์โทรศัพท์เช่นกัน)

แก้ไขปัญหาด้วยการบันทึกข้อมูลด้วย Primary key ซึ่งแทนกลุ่มข้อมูลเหล่านั้นแทน

วิธีการทำเพื่อแก้ปัญหานี้คือการสร้าง Table ขึ้นมาใหม่ โดยเอากลุ่มข้อมูลที่น่าจะเปลี่ยนแปลงบ่อยออกมา โดยแทนที่จะบันทึกข้อมูลของกลุ่มข้อมูลนั้นเข้าไปตรง เราจะบันทึกด้วย Primary key แทน

โดยการอ่านจะอ่านจาก Table appointments ซึ่งเป็น Table หลักดังนี้

เมื่อวันที่ 01/08/2025 เวลา 10:30
- รหัสการจอง 001
- รถทะเบียน กต.1150 ยี่ห้อ Honda รุ่น Civic
- ของลูกค้า รหัสลูกค้า 001
- จองบริการประเมินรถ 2 อย่าง: 
  บริการประเมินสภาพรถเบื้องต้น
  บริการตรวจสอบประวัติการใช้รถ
- สถานะ: รอการยืนยัน
- จองตรวจสภาพรถมือสอง วันที่ 12/08/2025 เวลา 12:00-13:00

ไม่ใช่ทุกกรณีต้องทำแบบนี้เสมอไป เพราะเพิ่มความซับซ้อนให้ระบบ หากเราไม่ต้องการให้ข้อมูลเหมือนกันทั้งระบบ ก็สามารถคงไว้แบบเดิมได้

ขั้นตอนที่ 5: ออกแบบ Database ให้รองรับการบันทึกข้อมูลหลาย ๆ อัน

สำหรับกรณีที่ลูกค้าหนึ่งคนสามารถเลือกหลายแพคเกจบริการ อย่างกรณีนี้คือการจองประเมินรถมือสอง ลูกค้าอาจจะเลือกหลายแพคเกจในการตรวจประเมินรถหนึ่งคัน ซึ่งก่อให้ก่อปัญหาในการบันทึกข้อมูลแพคเกจ โดยเราสามารถแก้ไขได้ดังนี้

5.1 เพิ่ม Column / Field ตามจำนวนบริการที่เป็นไปได้ เช่น service_1, service_2

วิธีนี้จะเรียบง่ายแต่อาจจะไม่รองรับ กรณีที่เราไม่รู้ลูกค้าจะเลือกกี่บริการ ถ้าเลือกมากกว่า 2 ต้องสร้างตารางใหม่

5.2 สร้าง Table เพิ่มเพื่อใช้เก็บข้อมูลแพคเกจที่รถแต่ละคันเลือก

วิธีการที่ยืดหยุ่นกว่าคือสร้าง Table ใหม่ แล้วเก็บข้อมูล Primary key ของตารางหลักแทน ในรูปแบบดังนี้

โดยการอ่านจะอ่านที่ Table apppointments ดังนี้

เมื่อวันที่ 01/08/2025 เวลา 10:30
- รหัสการจอง 001
- รถทะเบียน กต.1150 ยี่ห้อ Honda รุ่น Civic
- ของลูกค้า รหัสลูกค้า 001
- สถานะ: รอการยืนยัน
- จองตรวจสภาพรถมือสอง วันที่ 12/08/2025 เวลา 12:00-13:00

และเมื่อต้องการดูบริการที่ลูกค้าเลือกจะเริ่มอ่านจาก Table services ดังนี้

Service / บริการที่ต้องการ ของ appointment_id (รหัสการจอง) ที่เท่ากับ 1 มีดังนี้
- ประเมินสภาพรถเบื้องต้น
- ตรวจสอบประวัติการใช้รถ

หลาย ๆ ครั้งที่มาถึงจุดนี้จะรู้สึกยากต่อการอ่าน แต่วิธีนี้จะช่วยแก้ปัญหาเรื่องการบันทึกข้อมูลหลายอันในช่องเดียว อีกทั้งยังสามารถเพิ่มรายละเอียดเกี่ยวกับบริการแต่ละอันได้ในช่อง service_note อีกด้วย (ทั้งนั้นจะเห็นได้ว่า service อาจจะมีโอกาสเกิดข้อมูลซ้ำซ้อนได้ เราก็สามารถทำตามขั้นตอนที่ 4 ได้อีกรอบนึง)

ขั้นตอนที่ 6: ปรับปรุงรายละเอียดอื่น ๆ ตามความเหมาะสม

ในขั้นตอนนี้เป็นการเพิ่ม Field ข้อมูลอื่นที่จำเป็น รวมถึงการคาดการณ์ปัญหาอื่น ๆ ที่อาจจะเกิดขึ้นเช่น ควรเพิ่ม Field ข้อมูลบางอย่างเพิ่มมั้ย เช่นสถานะการจอง ภาพตัวรถเป็นต้น

การใช้ Generative AI ช่วยออกแบบ Database: เครื่องมือสำหรับยุค Digital

เมื่อเข้าใจหลักการแล้ว เราสามารถใช้ Generative AI ช่วยออกแบบ Database ได้อย่างมีประสิทธิภาพ

You are appointed as a database designer for an organization. 

What I will do is to type in the data usage requirements, and you are to do: 

1. Design a database by determining how many tables are needed and what data each table should record, along with sample data. Indicate the relationships (One-to-One, One-to-Many, Many-to-Many) between each table. For One-to-One relationships, combine them into a single table. If there are Many-to-Many relationships, create a bridge table to change the relationship to One-to-Many.

2. Display Entity-Relationship (ER) diagram as a image.

3. Create all necessary tables for the system with actual sample data in table format. 
The output should be in table format.

4. Explain the rationale behind the design decisions.

Requirement = <__อธิบายความสัมพันธ์แบบขั้นตอนที่ 1 __>

ตัวอย่างการใช้งานจริง

You are appointed as a database designer for an organization. 

What I will do is to type in the data usage requirements, and you are to do: 

1. Design a database by determining how many tables are needed and what data each table should record, along with sample data. Indicate the relationships (One-to-One, One-to-Many, Many-to-Many) between each table. For One-to-One relationships, combine them into a single table. If there are Many-to-Many relationships, create a bridge table to change the relationship to One-to-Many.

2. Display Entity-Relationship (ER) diagram as a image.

3. Create all necessary tables for the system with actual sample data in table format. 
The output should be in table format.

4. Explain the rationale behind the design decisions.

Entity Relationship = 
เมื่อวันที่ 01/08/2025 เวลา 10:30
- รถทะเบียน กต.1150 ยี่ห้อ Honda รุ่น Civic
- ของลูกค้า นาย Peter Oun
- จองบริการประเมินรถ 2 อย่าง: 
  บริการประเมินสภาพรถเบื้องต้น
  บริการตรวจสอบประวัติการใช้รถ
- สถานะ: รอการยืนยัน
- จองตรวจสภาพรถมือสอง วันที่ 12/08/2025 เวลา 12:00-13:00

หมายเหตุ: รถเป็นของลูกค้าได้คนเดียวนัดหมายจองตรวจสภาพรถมือสองโดยเลือกบริการได้หลายอย่าง

โดยหัวใจหลักคือการอธิบายความสัมพันธ์ของแต่ละข้อมูลเหมือนที่เราทำใน Workshop ซึ่งหากเราออกแบบ Database ไว้อย่างดีแล้ว ระบบ Generative AI จะสามารถสร้างหน้า Web App เพื่อรองรับการใช้งาน Database ตัวนี้ได้อย่างถูกต้องเลย

การพิม Prompt ทดลองสร้าง Web App เพื่อเก็บข้อมูลเหล่านี้

ตัวอย่าง Diagram การออกแบบ Database ในธุรกิจต่าง ๆ

ระบบบันทึกข้อมูลการขาย

โดยข้อมูลการซื้อ (Transaction) แต่ละ Record เป็นของลูกค้า 1 คน แต่ละข้อมูลการซื้อ มีสินค้าได้หลายอัน

ระบบบันทึกข้อมูลการสร้าง Post ของ User บนระบบ Social Media

โดยข้อมูลการ Post บน Platform แต่ละ Record เป็นของ User 1 คน แต่ละ Post มี Comment ได้หลายอัน แต่ละ Comment จะมี User ที่เป็นเจ้าของ Comment 1 คน

แหล่งเรียนรู้เพิ่มเติม

แหล่งเรียนรู้ที่อาจจะไม่เหมาะสำหรับมือใหม่ เพราะมีศัพท์เทคนิคเยอะ แต่สามารถเรียนรู้เพิ่มเติมได้

• ER Model
• Introduction to Database Normalization
• Machine Readable Format

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

November 8, 2025November 8, 2025Technology 3

คู่มือการใช้งาน Application ที่สร้างด้วย AppSheet สำหรับผู้ใช้งานทั่วไป ฉบับเข้าใจง่าย (AppSheet User Manual)

คู่มือแนะนำวิธีการใช้งาน Application ที่ทำด้วย Platform AppSheet สำหรับผู้ใช้งานที่ใช้งาน AppSheet

October 30, 2025October 30, 2025Technology 20

[Review] Designing Data+AI System That Last ในงาน Data+AI Day 2025

คุณกานต์ จาก ODDS-TEAM จะชวนทุกคนมาขบคิดเรื่อง “Designing Data+AI System” ว่าจะทำยังไงให้ระบบที่เราสร้างทนทานต่อการเปลี่ยนแปลงของเทคโนโลยี AI ที่พัฒนาไปทุกวัน

October 7, 2025October 18, 2025Technology 45

ใช้ Gemini สร้าง AppSheet App แบบ Vibe coding

Workshop สอนใช้ Gemini สร้าง AppSheet แบบจับมือทำ Step by Step พร้อม Prompt ที่สามารถก็อปปี้นำไปใช้ได้เลย

June 3, 2025June 19, 2025Technology 77

[Workshop] สร้าง History Log แอป ฯ บันทึกการแก้ไขข้อมูลด้วย AppSheet

แนวทางการสร้าง Application สำหรับเก็บข้อมูลการแก้ไขข้อมูลด้วย AppSheet เหมาะสำหรับการบันทึกประวัติการแก้ไขข้อมูล

• Facebook
• Twitter
• Line

AppSheet Low-Code No-Code Software Development

Worakarn Ounhattapradit

พีเตอร์ ผู้ตัดสินใจกระโดดข้ามสายงานจากนักออกแบบ มาสู่โลกแห่งเทคโนโลยี สนใจในเทคโนโลยีใหม่ ๆ ที่จะพัฒนาคุณภาพชีวิตคนให้ดีขึ้น อ่านรายละเอียดเพิ่มเติม