ผู้ช่วยออกแบบฐานข้อมูล SQL

สิ่งที่ต้องมีอยู่ในมือ

ไม่จำเป็นต้องเรียบร้อยสวยงาม ขอแค่มีอยู่จริงในรูปแบบที่คัดลอกไปวางได้

• รายการเอนทิตี คือคำนามที่ระบบของคุณต้องเก็บ ใช้ชื่อคอลัมน์จากไฟล์ตารางที่ใช้อยู่ก็ได้ และบ่อยครั้งดีกว่ารายการที่เกลามาแล้วด้วยซ้ำ
• กติกาธุรกิจที่เป็นตัวตัดสิน Cardinality เช่น ลูกค้าหนึ่งคนมีที่อยู่สองแห่งได้ไหม ออร์เดอร์หนึ่งใบแยกส่งหลายรอบได้หรือเปล่า AI คิดแทนไม่ได้ ถ้าไม่บอกมันจะถามกลับ หรือไม่ก็เดา
• คำถามสองถึงสามข้อที่ฐานข้อมูลนี้ต้องตอบให้ได้ เช่น ยอดขายรายวัน ออร์เดอร์ค้างส่งแยกตามอายุ หรือตารางงานของพรุ่งนี้ ข้อนี้คือตัวแบ่งระหว่าง Schema ที่ผ่าน Normalization กับ Schema ที่ใช้งานได้จริง
• ชื่อและเวอร์ชันของฐานข้อมูล ถ้าตัดสินใจไปแล้ว เช่น Postgres, MySQL, SQL Server หรือ SQLite
• ปริมาณข้อมูลและการเติบโตแบบคร่าว ๆ คำว่า "ออร์เดอร์หลักร้อยต่อวัน เก็บย้อนหลังห้าปี" พาไปคนละทางกับ "มีข้อมูลไม่กี่สิบรายการ"
• ข้อมูลเดิมที่ต้องยกมาด้วย พร้อมข้อกำหนดด้านการปฏิบัติตามกฎเกณฑ์ เช่น ข้อมูลส่วนบุคคล ระยะเวลาเก็บรักษา หรืออะไรที่ห้ามอยู่ตารางเดียวกับข้อมูลอื่น

ระดับความพร้อม: ต้องแก้ไขข้อมูลเล็กน้อย

ไฟล์นี้มีช่องในวงเล็บสองจุดคือ [Application Purpose] และ [List of Entities] จึงจัดอยู่ในระดับต้องแก้ไขข้อมูลเล็กน้อย ใช้เวลาแก้ไม่ถึงนาที แต่เป็นเส้นแบ่งระหว่าง Schema ที่ออกแบบมาเพื่อระบบของคุณ กับ Schema ที่ออกแบบมาเพื่อร้านค้าในตำราเรียน ถ้าปล่อยว่างไว้ คำตอบก็ยังมาอยู่ดี เพียงแต่จะเป็นคำตอบที่ใช้กับใครก็ได้

เครื่องมือและภาษา

ใช้ได้กับผู้ช่วย AI ทุกตัวที่รับข้อความยาว ไม่ต้องติดตั้งอะไรเพิ่ม และไม่ต้องมีบัญชีอื่นนอกจากบัญชีที่คุณใช้กับ AI อยู่แล้ว มีให้เลือกทั้งฉบับภาษาไทยและภาษาอังกฤษ ดาวน์โหลดฟรีทั้งคู่หลังเข้าสู่ระบบ ฉบับภาษาอังกฤษใช้ Token น้อยกว่าอย่างเห็นได้ชัด ซึ่งสำคัญถ้าคุณจ่ายค่า API เป็นรายครั้ง หรือกำลังต่อไฟล์นี้เข้ากับ AI Agent ที่รันซ้ำ ๆ อัตโนมัติ

พื้นฐานที่ไฟล์นี้ถือว่าคุณมี

คุณควรอ่านคำสั่ง CREATE TABLE ออก และดูได้ว่าคีย์นอกชี้ไปตรงที่ที่ควรจะเป็นหรือไม่ ไม่จำเป็นต้องท่องได้ว่า Normal Form แต่ละขั้นคืออะไร เพราะไฟล์อธิบายเหตุผลไปพร้อมกับที่ออกแบบอยู่แล้ว แต่ผลลัพธ์ที่คุณตรวจสอบเองไม่ได้ ก็ไม่ใช่ผลลัพธ์ที่ควรส่งขึ้นระบบ และข้อนี้จริงกับงานออกแบบฐานข้อมูลยิ่งกว่างานเกือบทุกอย่างที่ AI เขียนให้คุณได้

บทบาทที่กำหนดให้ AI

บรรทัดแรกกำหนดตัวตนให้ AI ว่า “คุณคือผู้ดูแลฐานข้อมูลอาวุโสที่เชี่ยวชาญด้านการออกแบบฐานข้อมูลเชิงสัมพันธ์และการเขียนสคริปต์ SQL” บทบาทเปลี่ยนคลังศัพท์ สมมติฐาน และระดับความละเอียดที่ AI เลือกใช้

โครงสร้างของคำสั่ง ทีละส่วน

แต่ละหัวข้อวางไว้แก้คนละจุด

• ข้อมูลที่ต้องเก็บ — เก็บข้อมูลที่ AI ไม่มีทางเดาเองได้
• วิธีทำงาน — กำหนดลำดับการคิดให้เป็นขั้นเป็นตอน
• ข้อห้าม — ปิดช่องที่ผลลัพธ์มักเพี้ยน
• รูปแบบผลลัพธ์ — ล็อกหน้าตาของผลลัพธ์

ทำไมถึงได้ผลนิ่งกว่าการพิมพ์ถามเอง

เทียบกับการพิมพ์ถามสั้น ๆ คำสั่งนี้ตัดโอกาสที่ AI จะเดาออกทีละจุด

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

วิธีรัน

คัดลอกเนื้อหาไฟล์ไปวางเป็นข้อความแรกของบทสนทนาใหม่ ห้ามวางต่อท้ายบทสนทนาเดิมที่มีเรื่องอื่นค้างอยู่ เพราะบริบทเก่าจะแย่งกับกติกาในไฟล์ และอาการที่เจอคือ AI ค่อย ๆ ทิ้งรูปแบบผลลัพธ์ไปกลางทางแบบเงียบ ๆ จากนั้นแทนค่าในวงเล็บทั้งสองจุด ถ้ารู้อยู่แล้วว่าจะใช้ฐานข้อมูลตัวไหน ให้ระบุชื่อและเวอร์ชันไปในข้อความเดียวกัน เพราะไฟล์นี้ตั้งใจเลี่ยงไวยากรณ์เฉพาะแพลตฟอร์มจนกว่าคุณจะระบุ การพิมพ์ว่า "Postgres 16" คือสิ่งที่ปลดล็อกให้ได้ TIMESTAMPTZ และ JSONB แทนชนิดข้อมูลกลาง ๆ แบบ ANSI

• [Application Purpose] — เขียนหนึ่งถึงสองประโยคว่าระบบนี้ทำอะไร โดยใส่ส่วนที่ทำให้ระบบของคุณไม่เหมือนที่อื่นลงไปด้วย คำว่า "ร้านค้าออนไลน์" ได้คำตอบกลาง ๆ แต่ "ร้านเบเกอรี่สั่งทำที่มีรอบจัดส่งและไม่สต็อกสินค้า" ได้ Schema ที่คิดเรื่องรอบจัดส่งมาให้แล้ว
• [List of Entities] — ใส่คำนามที่คุณรู้อยู่แล้วว่าต้องเก็บ ไม่ต้องเกลารายการให้สวยก่อน เพราะเอนทิตีที่ขาดไปมองเห็นง่ายกว่าตอนอยู่ใน Schema มากกว่าตอนอยู่บนหน้ากระดาษเปล่า
• ไม่บังคับแต่ควรใส่: รายงานที่คุณเปิดดูบ่อยที่สุด เขียนสั้น ๆ หนึ่งประโยค เพราะมันเปลี่ยนว่าคีย์ควรไปวางอยู่ตรงไหน

กรณีใช้งานที่ 1 — ไฟล์ตารางที่ใหญ่เกินตัวไปแล้ว

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

กรณีใช้งานที่ 2 — ระบบจองและจัดตาราง ที่เจอ M:N ตั้งแต่ต้น

งานที่มีนัดหมาย ห้อง คลาสเรียน หรือกะทำงาน จะชนความสัมพันธ์แบบ M:N ตั้งแต่สามตารางแรก และไดอะแกรมที่วาดมือมักจับมันยัดเป็นคอลัมน์เดียว วิธีที่ได้ผลคือเขียนกติกาธุรกิจออกมาเป็นกติกาตรง ๆ เช่น "หนึ่งนัดหมายใช้หนึ่งห้อง แต่มีแพทย์ได้สองคน" แล้วผลลัพธ์จะกลับมาพร้อมตารางกลางและเหตุผลว่าทำไมถึงต้องมี Cardinality เป็นการตัดสินใจเชิงธุรกิจ ไม่ใช่เชิงเทคนิค AI คิดแทนคุณไม่ได้ ประโยคที่คุณเสียเวลาเขียนอธิบายกติกาจึงเป็นประโยคที่คุ้มที่สุดในข้อความทั้งหมด

กรณีใช้งานที่ 3 — ใช้รีวิว Schema ที่ใช้งานอยู่แล้ว

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

เทคนิคการปรับแต่งและข้อควรทำ

นี่คือการปรับที่แยกระหว่าง Schema ที่ส่งขึ้นระบบได้จริง กับ Schema ที่เป็นแค่ตัวอย่างสาธิตหลัก Normal Form ทุกข้อเป็นแค่บรรทัดเดียวที่เติมลงในข้อความของคุณ ไม่ต้องแก้ตัวไฟล์เลย

• ระบุชื่อและเวอร์ชันของฐานข้อมูล ถ้าไม่ระบุ คำตอบจะอยู่กับชนิดข้อมูลกลาง ๆ แบบ ANSI ซึ่งปลอดภัยแต่มักไม่ใช่สิ่งที่คุณต้องการ
• ขอคำสั่งสืบค้นที่คุณใช้จริง ไม่ใช่ตัวอย่างทั่วไป Schema ที่ตอบรายงานประจำวันของคุณไม่ได้ ถือว่าออกแบบผิด ต่อให้ผ่าน Normalization ครบทุกข้อ
• รันสองรอบ รอบแรกเอา Schema รอบสองสั่งว่า "ทีนี้ช่วยเขียนคำสั่งสืบค้นสามชุดที่ Schema นี้ทำได้ยากที่สุด" ความผิดพลาดเรื่องคีย์มักโผล่ในรอบสอง
• เวลาผลลัพธ์ไม่ตรงใจ ให้แก้ทีละหัวข้อ ถ้าแก้สองหัวข้อพร้อมกันในรอบเดียว สุดท้ายคุณจะไม่รู้ว่าจุดไหนคือจุดที่ได้ผล
• ตกลงหลักการตั้งชื่อให้จบก่อนถึงตารางที่สี่สิบ ทั้งเรื่องเอกพจน์หรือพหูพจน์ การใช้ snake_case และรูปแบบชื่อคีย์นอก แล้วเขียนกำกับไปในข้อความ เพราะการเปลี่ยนชื่อทีหลังคือการทำ Migration
• 3NF คือพื้นขั้นต่ำ ไม่ใช่เส้นชัย ถ้าจะ Denormalize ให้ทำอย่างตั้งใจหลังมีตัวเลขวัดผลแล้ว ไม่ใช่เพราะเห็นคำสั่ง JOIN ยาวแล้วรู้สึกไม่สบายใจ
• สั่งให้ระบุชนิดข้อมูลของเงิน เวลา และรหัสอ้างอิงให้ชัด ใช้ DECIMAL แทน FLOAT ใช้เวลาที่มี Timezone และให้บอกจุดยืนเรื่องคีย์ธรรมชาติกับคีย์สังเคราะห์
• ถ้าคุณกำลังสร้าง Prompt ของตัวเองไว้ใช้ในทีม ให้ยืมโครงของไฟล์นี้ไป คือบทบาท ข้อมูลที่ต้องเก็บ วิธีทำงาน ข้อห้าม และรูปแบบผลลัพธ์ แล้วเปลี่ยนแค่เนื้องาน โครงนี้คือส่วนที่ย้ายไปใช้กับงานอื่นได้จริง

ตัวแปรที่ต้องกรอกก่อนใช้งาน

แทนช่องในวงเล็บด้วยข้อมูลของคุณ ยิ่งเจาะจงยิ่งใช้ได้จริง

• [Application Purpose]
• [List of Entities]

ปรับความเข้มของข้อกำหนด

ปรับข้อกำหนดต่อจากตัวแปร แก้ทีละอย่าง ไม่งั้นจะไม่รู้ว่าอันไหนได้ผล

• แก้หัวข้อ “รูปแบบผลลัพธ์” เพื่อเปลี่ยนหน้าตาผลลัพธ์ เช่น เปลี่ยนเป็นตาราง หรือกำหนดความยาว
• เพิ่มหรือลดบรรทัดในหัวข้อ “ข้อห้าม” คือวิธีคุมผลที่ตรงที่สุด หลุดกรอบซ้ำ ๆ ให้เติมข้อห้ามหนึ่งบรรทัด
• ระบุกลุ่มผู้อ่านให้แคบลง เช่น จาก “ลูกค้าทั่วไป” เป็น “เจ้าของร้านอายุ 30–45 ปีที่ไม่ถนัดศัพท์เทคนิค”
• ไฟล์นี้ยังไม่มีส่วนกำหนดสไตล์ เติมบรรทัดสั้น ๆ ว่าอยากได้โทนไหน ผลจะไม่แกว่งระหว่างรอบ

แก้เล็กน้อยก่อนใช้ก็พอ

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

ต่อเป็น Workflow หลายขั้น

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

คำตอบสามส่วน

เรียงตามลำดับนี้เสมอ ไม่ว่าเนื้องานจะเป็นเรื่องอะไร

• คำอธิบายแบบร้อยแก้วว่าเอนทิตีแต่ละตัวสัมพันธ์กันอย่างไร บอกครบว่ามีตารางอะไรบ้าง แต่ละตารางเก็บอะไร และ Cardinality ของแต่ละความสัมพันธ์เขียนออกมาตรง ๆ ว่าเป็น 1:1, 1:N หรือ M:N ไม่ใช่ปล่อยให้เดาเอง
• คำสั่ง DDL คือ CREATE TABLE ที่เลือกชนิดข้อมูลรายคอลัมน์ ประกาศคีย์หลักไว้ชัด และประกาศคีย์นอกเป็น Constraint จริง ไม่ใช่แค่พูดถึงลอย ๆ
• คำสั่งสืบค้นที่ซับซ้อนหนึ่งชุด เชื่อมตารางเหล่านั้นสำหรับกรณีใช้งานจริง และเขียนให้ตรงกับคำสั่ง DDL ที่อยู่เหนือมันขึ้นไป

รอบที่ดีหน้าตาเป็นอย่างไร

ให้อ่านคำสั่ง DDL ก่อนอ่านคำอธิบาย เพราะคำอธิบายคือที่ที่รอบแย่ ๆ ใช้ซ่อนตัว รายการด้านล่างคือการตรวจที่ใช้เวลาสามสิบวินาทีแต่คุ้ม

• ความสัมพันธ์แบบ M:N ทุกจุดต้องมีตารางกลางจริง พร้อมคีย์นอกทั้งสองฝั่งและคีย์หลักที่สมเหตุสมผล
• ต้องไม่มีคอลัมน์ไหนเก็บค่าเป็นรายการ ถ้าเห็นค่าคั่นด้วยจุลภาคเมื่อไร แปลว่าขั้นตอน Normalization ยังทำไม่จบ
• ชนิดข้อมูลต้องเจาะจง ใช้ DECIMAL กับจำนวนเงิน ใช้เวลาที่มี Timezone กับทุกอย่างที่เกี่ยวกับการนัดหมาย และระบุจุดยืนว่าจะใช้คีย์ธรรมชาติหรือคีย์สังเคราะห์
• คำสั่งสืบค้นตัวอย่างต้องรันกับตารางที่อยู่ข้างบนได้จริง ชื่อคอลัมน์ตรงกัน คีย์ตรงกัน ถ้าคำสั่งอ้างถึงคอลัมน์ที่ไม่มีอยู่ นั่นคือสัญญาณชัดที่สุดว่าต้องรันใหม่
• คำตอบต้องอ้างถึงเอนทิตีที่คุณให้ไปจริง ไม่ใช่ร้านค้าสมมติ ถ้าคำตอบออกมาใช้กับใครก็ได้ แปลว่ามีช่องในวงเล็บที่ยังไม่ได้แทนค่า

สิ่งที่คำสั่งนี้จะไม่ทำ

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

• ไม่ใช้ไวยากรณ์เฉพาะแพลตฟอร์มจนกว่าคุณจะระบุแพลตฟอร์ม ข้อนี้เป็นค่าตั้งต้นของไฟล์ ไม่ใช่ข้อจำกัดของ AI
• ไม่แต่งสถิติ ผลทดสอบ หรือแหล่งอ้างอิงขึ้นมาเอง ถ้าถามในสิ่งที่มันไม่รู้ ไฟล์กำหนดให้ตอบว่าไม่ทราบ
• ไม่ให้แผนการย้ายข้อมูลจริงและไม่ให้แผนย้อนกลับ การย้ายข้อมูลที่มีอยู่แล้วเป็นคนละปัญหาและมีความเสี่ยงคนละชุด
• ไม่ให้การจูน Index ที่เชื่อถือได้ เพราะการตัดสินใจเรื่อง Index จริงต้องดูจาก Query Plan บนปริมาณข้อมูลจริง ซึ่งเป็นสิ่งที่ AI มองไม่เห็น
• หยุดอยู่ที่ 3NF การออกแบบแบบ Star Schema งาน Data Warehouse หรือระบบที่เก็บเป็นลำดับเหตุการณ์ เป็นคนละศาสตร์ และไฟล์นี้จะไม่แกล้งทำเป็นว่าทำได้
• ไม่ตัดสินกติกาธุรกิจแทนคุณ จุดไหนที่ Cardinality ขึ้นอยู่กับวิธีทำงานขององค์กรคุณ ไฟล์กำหนดให้ถามกลับแทนการเดา

ก่อนนำขึ้นใช้งานจริง

ให้ถือว่าผลลัพธ์คือข้อเสนอที่ผ่านการรีวิวแล้ว ไม่ใช่ Migration ที่พร้อมรัน เอาคำสั่ง DDL ไปรันบนฐานข้อมูลทดสอบให้แน่ใจก่อนว่าทำงานผ่าน จากนั้นรันคำสั่งสืบค้นตัวอย่างกับจำนวนแถวที่ใกล้เคียงของจริงแล้วอ่าน Query Plan สุดท้ายให้ตัดสินใจเรื่องพฤติกรรมการลบของคีย์นอกทุกตัวด้วยมือ กติกา Cascade คือสิ่งเดียวที่ Schema พลาดได้แบบเงียบที่สุด และวันที่คุณรู้ตัวมักเป็นวันเดียวกับที่ข้อมูลสำคัญหายไปแล้ว