Glossary · มือใหม่

ศัพท์ที่ควรรู้

เจอคำไหนไม่เข้าใจ เปิดหน้านี้— รวมคำที่มือใหม่เจอบ่อยทั่วห้องสมุด อธิบายภาษาไทยง่าย ๆ พร้อมตัวอย่างทุกคำ

ใช้หน้านี้ยังไง

อ่านบทความในห้องสมุดแล้วเจอคำแปลก ๆ เป็นภาษาอังกฤษ? คำพวกนี้ ไม่ต้องท่อง— แค่รู้ว่ามันหมายถึงอะไรพอ. เลือกหมวดจากแถบด้านบน หรือเลื่อนอ่านทั้งหน้า แต่ละคำมี คำแปล + คำอธิบายสั้น + ตัวอย่างจริงให้เห็นภาพ

ข้อมูลสิทธิ์ & ผู้ใช้เว็บ & ระบบDeploy & โครงสร้างAIUI

ข้อมูล

คำที่เจอเวลาพูดถึงการเก็บข้อมูลและตาราง

data
แหล่งข้อมูลจริงหนึ่งเดียว
SSOT · Single Source of Truth
หลักการว่าข้อมูลแต่ละชิ้นควรมี ที่เก็บจริงที่เดียวใครจะใช้ก็ดึงจากที่นั่น ไม่ก๊อปไปไว้หลายที่จนข้อมูลเพี้ยนไม่ตรงกัน
เช่นเบอร์ลูกค้าเก็บในทะเบียนลูกค้าที่เดียว ทุกใบเสร็จ/ทุกหน้าดึงจากตรงนั้น แก้ที่เดียวเปลี่ยนทั้งระบบ
data
ทะเบียนกลาง
Master Data
ข้อมูลตั้งต้นที่ใช้ซ้ำทั่วระบบ เช่น รายชื่อสินค้า ลูกค้า พนักงาน ตั้งไว้ครั้งเดียวแล้วเรียกใช้ไม่ต้องพิมพ์ใหม่ทุกครั้ง
เช่นทะเบียนสินค้า 200 รายการ — เวลาออกใบเสร็จก็เลือกจากทะเบียน ไม่ต้องพิมพ์ชื่อ-ราคาเองทุกที
data
เพิ่ม-อ่าน-แก้-ลบ
CRUD
4 อย่างพื้นฐานที่ทำกับข้อมูล: Create เพิ่ม · Read อ่าน · Update แก้ · Delete ลบ. เกือบทุกหน้าจัดการข้อมูลคือ CRUD
เช่นหน้า "จัดการสินค้า" = เพิ่มสินค้าใหม่ · ดูรายการ · แก้ราคา · ลบของที่เลิกขาย ครบ CRUD
data
รหัสอ้างอิง
Foreign key
ช่องในตารางหนึ่งที่ ชี้ไปหาแถวในอีกตารางเพื่อเชื่อมข้อมูลเข้าด้วยกัน แทนที่จะเก็บข้อมูลซ้ำ
เช่นใบเสร็จเก็บแค่ "รหัสลูกค้า #42" ชี้ไปทะเบียนลูกค้า แทนที่จะเก็บชื่อ-ที่อยู่ซ้ำในทุกใบ
data
โครงตาราง
Schema
แบบแปลนว่าตารางข้อมูลมี ช่องอะไรบ้าง ชนิดไหน(ตัวเลข/ข้อความ/วันที่) — เหมือนหัวตาราง Excel ที่กำหนดไว้ล่วงหน้า
เช่นตารางลูกค้ามีช่อง: ชื่อ (ข้อความ), เบอร์ (ข้อความ), ยอดซื้อ (ตัวเลข), วันสมัคร (วันที่)
data
ลบแบบซ่อน
Soft delete
เวลา "ลบ" ข้อมูล ไม่ลบจริง แค่ติดธงว่าซ่อนไว้— ข้อมูลยังอยู่ในฐาน กู้คืนได้ และไม่ทำให้รายการเก่าที่อ้างถึงมันพัง
เช่นลบพนักงานที่ลาออก แต่สลิปเงินเดือนเดือนเก่ายังอ้างชื่อเขาได้ เพราะข้อมูลแค่ถูกซ่อน ไม่ได้หายจริง

สิทธิ์ & ผู้ใช้

ใครเป็นใคร และใครทำอะไรได้บ้าง

auth
การยืนยันตัวตน / ล็อกอิน
Authentication · Login
ขั้นตอนพิสูจน์ว่า คุณคือคุณจริงก่อนเข้าระบบ — ผ่านรหัสผ่าน, OTP, หรือล็อกอินด้วย LINE/Google
เช่นพนักงานกรอกอีเมล+รหัสผ่านเพื่อเข้าหน้าทำงาน ระบบเช็คว่าตรงไหม ถึงให้เข้า
auth
บทบาท
Role
ป้ายกำหนดว่าผู้ใช้คนนี้ เป็นใครในระบบเช่น เจ้าของ / ผู้จัดการ / พนักงาน — แต่ละบทบาทเห็นและทำได้ไม่เท่ากัน
เช่นบทบาท "เจ้าของ" เห็นกำไร-ขาดทุน แต่บทบาท "พนักงาน" เห็นแค่งานของตัวเอง
auth
สิทธิ์ตามบทบาท
RBAC
วิธีจัดการสิทธิ์โดย ผูกกับบทบาท ไม่ใช่รายคน— ตั้งครั้งเดียวว่าแต่ละบทบาททำอะไรได้ ใครได้บทบาทไหนก็ได้สิทธิ์นั้นทันที
เช่นกำหนดว่า "ผู้จัดการ" อนุมัติใบลาได้ — พอตั้งใครเป็นผู้จัดการ คนนั้นอนุมัติได้เลย ไม่ต้องตั้งสิทธิ์ทีละคน
auth
หลายบริษัทในระบบเดียว
Multi-tenant
ระบบเดียวที่ รองรับหลายองค์กรพร้อมกันแต่ข้อมูลแต่ละบริษัทแยกขาดจากกัน มองไม่เห็นข้ามกัน
เช่นโปรแกรมบัญชีตัวเดียวให้ร้าน A และร้าน B ใช้ ต่างคนต่างเห็นแค่ข้อมูลร้านตัวเอง
auth
สิทธิ์การใช้งาน
Permission
การอนุญาตรายอย่างว่า ทำสิ่งนี้ได้หรือไม่เช่น "ดูเงินเดือน" "ลบข้อมูล" "อนุมัติ" — เป็นชิ้นย่อยที่ประกอบกันเป็นบทบาท
เช่นเปิดสิทธิ์ "ส่งออกรายงาน" ให้หัวหน้าทีม แต่ปิดสิทธิ์ "ลบลูกค้า" ไว้

เว็บ & ระบบ

ส่วนประกอบหลักของเว็บแอปทำงานยังไง

ภาพรวมคำในหมวดนี้ต่อกันเป็นเส้นเดียว — กดปุ่มหนึ่งที ข้อมูลวิ่งผ่านทุกชิ้นแล้วกลับมา
ผู้ใช้user
หน้าบ้านfrontend
API
หลังบ้านbackend
ฐานข้อมูลdatabase

กดส่งใบลา → หน้าบ้านยิงคำขอผ่าน APIหลังบ้านเช็คสิทธิ์+คำนวณ → อ่าน/เขียน ฐานข้อมูล → คำตอบวิ่งย้อนกลับมาขึ้นจอ. ส่วน Webhook คือทิศกลับกัน — ระบบอื่น (เช่น LINE) ยิงเข้ามาหาหลังบ้านเองโดยเราไม่ต้องถาม

web
หน้าบ้าน
Frontend
ส่วนที่ ผู้ใช้เห็นและกดได้บนหน้าจอ — ปุ่ม ฟอร์ม ตาราง สี ทั้งหมดที่แสดงในเบราว์เซอร์/มือถือ
เช่นหน้าจอกรอกใบลาที่พนักงานเห็น มีช่องกรอกเหตุผลและปุ่มส่ง = หน้าบ้าน
web
หลังบ้าน
Backend
ส่วนที่ทำงาน เบื้องหลังที่ผู้ใช้มองไม่เห็น— รับคำสั่งจากหน้าบ้าน คำนวณ ตรวจสิทธิ์ บันทึก/อ่านฐานข้อมูล
เช่นพอกดส่งใบลา หลังบ้านเช็คว่าวันลาเหลือพอไหม แล้วบันทึก+แจ้งหัวหน้า
web
ฐานข้อมูล
Database
ที่ เก็บข้อมูลถาวรของระบบ จัดเป็นตารางให้ค้น เพิ่ม แก้ ลบ ได้เร็วและไม่หาย — หัวใจของทุกแอป
เช่นรายชื่อลูกค้า ใบเสร็จทั้งหมด ประวัติการลา ถูกเก็บในฐานข้อมูล ปิดเครื่องก็ไม่หาย
web
ช่องทางคุยกันของระบบ
API
ประตูมาตรฐานให้ หน้าบ้านขอข้อมูล/สั่งงานหลังบ้านหรือให้ระบบอื่นมาเชื่อมต่อ — เหมือนเมนูสั่งอาหารที่บอกว่าขออะไรได้บ้าง
เช่นหน้าบ้านเรียก API "ขอรายการสินค้า" หลังบ้านส่งกลับมาเป็นข้อมูลให้แสดงผล
web
การแจ้งเตือนอัตโนมัติ
Webhook
วิธีให้ระบบอื่น ยิงข้อความมาบอกเราทันทีเมื่อมีเหตุการณ์โดยเราไม่ต้องคอยถาม — ตรงข้ามกับ API ที่เราเป็นฝ่ายไปขอ
เช่นมีคนทักแชต LINE → LINE ยิง webhook มาบอกระบบเราทันที ระบบเลยตอบกลับได้

Deploy & โครงสร้าง

การเอาเว็บขึ้นให้คนอื่นใช้จริง

deploy
โฮสต์ / ที่ฝากเว็บ
Hosting
เครื่องเซิร์ฟเวอร์ที่ เก็บเว็บไว้ให้เปิดออนไลน์ได้ตลอดไม่ใช่รันแค่บนคอมเราเครื่องเดียว — เหมือนเช่าพื้นที่ให้ร้านเปิดได้ 24 ชม.
เช่นอัปเว็บขึ้นโฮสต์ (เช่น Cloudflare Pages) แล้วลูกค้าทั่วประเทศเปิดดูได้พร้อมกัน
deploy
โดเมน / ชื่อเว็บ
Domain
ชื่อที่อยู่เว็บที่คนพิมพ์เข้า เช่น skills-lab.co— เป็นชื่อจำง่ายแทนเลข IP ของเครื่องเซิร์ฟเวอร์
เช่นซื้อโดเมน myshop.com แล้วชี้มาที่โฮสต์ ลูกค้าพิมพ์ชื่อนี้ก็เจอร้าน
deploy
สมุดที่อยู่ของอินเทอร์เน็ต
DNS
ระบบที่ แปลงชื่อโดเมนเป็นเลข IPของเซิร์ฟเวอร์จริง เหมือนสมุดโทรศัพท์ที่แปลงชื่อคนเป็นเบอร์
เช่นพิมพ์ myshop.com → DNS บอกว่าจริง ๆ คือเครื่องเลข 104.21.x.x → เบราว์เซอร์เลยไปถูกที่
deploy
ค่าลับ / ตัวแปรสภาพแวดล้อม
Secret · Env variable
ค่าสำคัญที่ ไม่เขียนปนในโค้ดเช่น รหัสผ่านฐานข้อมูล กุญแจ API — เก็บแยกไว้ปลอดภัย เปลี่ยนได้โดยไม่แก้โค้ด
เช่นกุญแจส่งข้อความ LINE เก็บเป็น secret ในโฮสต์ ไม่ใส่ในไฟล์โค้ดที่อาจหลุดออกไป
deploy
การประกอบเว็บ
Build
ขั้นตอน แปลงโค้ดที่เราเขียนให้เป็นไฟล์พร้อมใช้งานจริง— รวมไฟล์ ย่อขนาด เช็คความถูกต้อง ก่อนเอาขึ้นออนไลน์
เช่นกดสั่ง build → ระบบรวมโค้ดทั้งหมดเป็นชุดไฟล์เล็กกระชับที่เบราว์เซอร์โหลดเร็ว
deploy
การปล่อยขึ้นใช้งานจริง
Deploy
การ เอาเว็บที่ build แล้วขึ้นโฮสต์ให้เปิดออนไลน์จริง — หลัง deploy ผู้ใช้ก็เห็นเวอร์ชันใหม่ทันที
เช่นแก้บั๊กเสร็จ → กด deploy → อีก 1 นาทีลูกค้าเปิดเว็บก็ได้เวอร์ชันที่แก้แล้ว

AI

คำที่เจอเวลาทำงานกับปัญญาประดิษฐ์

ai
คำสั่ง / คำถามที่ป้อนให้ AI
Prompt
ข้อความที่เรา พิมพ์สั่งหรือถาม AI— สั่งชัดและให้ข้อมูลครบ ผลลัพธ์ก็ดีและตรงขึ้น
เช่นprompt "สรุปยอดขายเดือนนี้เป็น 3 ข้อ ภาษาทางการ" ได้สรุปตรงกว่าพิมพ์ลอย ๆ ว่า "ยอดขาย"
ai
บริบท
Context
ข้อมูลแวดล้อมที่ ป้อนให้ AI รู้ก่อนตอบเพื่อให้ตอบตรงกับสถานการณ์เรา ไม่ใช่ตอบแบบทั่วไป
เช่นให้ context "ร้านขายเครื่องสำอาง ลูกค้าผู้หญิง 25-35" AI ก็เขียนแคปชันให้เข้ากลุ่มนี้
ai
คำนวณด้วยสูตร ไม่ใช่ AI เดา
Deterministic
ผลลัพธ์ที่ ได้จากสูตรตายตัว ใส่ค่าเดิมได้คำตอบเดิมเป๊ะทุกครั้ง— ตรงข้ามกับให้ AI เดา ที่อาจไม่เป๊ะ. เรื่องเงิน/ภาษีต้องใช้แบบนี้
เช่นคำนวณภาษีหัก ณ ที่จ่ายใช้สูตรกฎหมายตรง ๆ (deterministic) ไม่ปล่อยให้ AI เดาเลข
ai
โมเดลภาษาขนาดใหญ่
LLM
สมอง AI ที่ เข้าใจและสร้างภาษาคนได้เพราะเรียนจากข้อความมหาศาล — เบื้องหลังของแชตบอท ผู้ช่วยเขียน สรุป แปล
เช่นผู้ช่วย AI ในระบบที่ตอบคำถาม สรุปเอกสาร ร่างอีเมล ทำงานด้วย LLM อยู่เบื้องหลัง

UI

ชิ้นส่วนหน้าจอที่เจอบ่อยเวลาออกแบบ

ui
ชิ้นส่วนหน้าจอ
Component
ชิ้นส่วน UI ที่ ทำครั้งเดียวแล้วเอาไปใช้ซ้ำได้ทั้งระบบเช่น ปุ่ม การ์ด ช่องค้นหา — แก้ที่ต้นแบบ เปลี่ยนทุกที่ที่ใช้
เช่นทำ component "ปุ่มหลัก" ไว้ครั้งเดียว ทุกหน้าเรียกใช้ หน้าตาเหมือนกันหมด
ui
ข้อความเด้งแจ้งเตือน
Toast
กล่องข้อความเล็ก ๆ ที่ เด้งขึ้นมาแจ้งผลแล้วหายไปเองไม่บล็อกหน้าจอ ใช้บอกผลการกระทำที่ผ่านไปแล้ว
เช่นกดบันทึกสำเร็จ → toast "บันทึกแล้ว ✓" เด้งมุมจอ 2 วินาทีแล้วหาย
ui
หน้าต่างซ้อน
Modal
กล่องที่ เด้งทับหน้าจอ ทำให้พื้นหลังจางและกดไม่ได้จนกว่าจะจัดการเสร็จ — ใช้กับสิ่งที่ต้องตัดสินใจก่อนไปต่อ
เช่นกดลบข้อมูล → modal เด้งถาม "แน่ใจไหม? ลบแล้วกู้ไม่ได้" ต้องกดยืนยันหรือยกเลิกก่อน
ui
ตรวจฟอร์ม
Validation
การ เช็คข้อมูลที่ผู้ใช้กรอกก่อนส่งว่าครบและถูกรูปแบบไหม ถ้าผิดก็ชี้ช่องที่ต้องแก้ ป้องกันข้อมูลเสียเข้าระบบ
เช่นกรอกอีเมลไม่มี @ → ฟอร์มขึ้นสีแดงใต้ช่อง "อีเมลไม่ถูกต้อง" ก่อนยอมให้กดส่ง
ui
หน้าจอตอนยังไม่มีข้อมูล
Empty state
สิ่งที่แสดงเมื่อ ยังไม่มีข้อมูลให้โชว์— แทนจอว่างเปล่า ควรบอกว่าเกิดอะไรขึ้น + ชวนทำขั้นแรก
เช่นเปิดหน้ารายการลูกค้าครั้งแรก ยังไม่มีใคร → โชว์ "ยังไม่มีลูกค้า — กดเพิ่มคนแรกเลย" พร้อมปุ่ม
กลับห้องสมุดออกแบบ

อ่านต่อ — เรื่องที่เกี่ยวข้อง

Vibe ERP คืออะไร เริ่มยังไง เริ่มวันแรก — เตรียมเครื่องมือ วิธีสั่ง AI สร้างระบบ (Prompt) คัมภีร์ UI — ปุ่ม·Toast·Modal