วิธีใส่คำอธิบายคอลัมน์ใน PostgreSQL และ MySQL ให้ปลอดภัยและเป็นระเบียบ

ทำไมการใส่คำอธิบายในฐานข้อมูลถึงกลายเป็นเรื่องยากสำหรับโปรแกรมเมอร์

เวลาเราเขียนโค้ด เรามักจะใส่ Comment หรือคำอธิบายกำกับไว้เสมอเพื่อให้เพื่อนร่วมทีมหรือตัวเราเองในอนาคตกลับมาอ่านแล้วเข้าใจว่าฟังก์ชันนี้ทำหน้าที่อะไร แต่ในโลกของ Database (ฐานข้อมูล) การใส่คำอธิบายให้กับคอลัมน์ (Column Comments) กลับเป็นเรื่องที่โปรแกรมเมอร์หลายคนมองข้ามหรือไม่ค่อยอยากทำ ทั้งที่มันสำคัญมากต่อการดูแลระบบระยะยาว

สาเหตุหลักไม่ใช่เพราะขี้เกียจครับ แต่เป็นเพราะกระบวนการทำงานแบบเดิมมัน ยุ่งยากเกินไป การจะเพิ่มคำอธิบายหนึ่งประโยคลงในฐานข้อมูล คุณมักจะต้องทำผ่านสิ่งที่เรียกว่า Migration (ไฟล์สคริปต์ที่ใช้จัดการโครงสร้างฐานข้อมูล) ซึ่งต้องผ่านขั้นตอนการเขียนโค้ด การรีวิว และการ Deploy ขึ้นเซิร์ฟเวอร์จริง เหมือนกับการเปลี่ยนโครงสร้างฐานข้อมูลใหญ่ๆ ทั้งที่จริงๆ แล้วมันเป็นแค่ "คำอธิบาย" เท่านั้นเอง

ลองนึกภาพว่าคุณอยากจะเขียนโน้ตแปะไว้ที่หน้าตู้เย็นว่า "น้ำส้มหมดอายุวันที่ 20" แต่กฎของบ้านคือคุณต้องทำเรื่องเบิกงบประมาณผ่านสภาหมู่บ้านเพื่อจ้างช่างมาเปลี่ยนบานตู้เย็นใหม่เพียงเพื่อจะติดสติกเกอร์ใบเดียว นี่คือความรู้สึกของโปรแกรมเมอร์เวลาต้องทำ Schema Change (การเปลี่ยนโครงสร้างฐานข้อมูล) เพียงเพื่อเพิ่มคำอธิบายสั้นๆ ครับ

ความต่างของ PostgreSQL และ MySQL กับการจัดการคำอธิบาย

ในฝั่งของ PostgreSQL นั้นถือว่าทำได้ค่อนข้างเป็นมิตรครับ มันมีคำสั่งเฉพาะที่ชื่อว่า COMMENT ON COLUMN ซึ่งช่วยให้เราเพิ่มคำอธิบายเข้าไปในตารางได้โดยตรงโดยไม่กระทบกับข้อมูลหรือโครงสร้างหลักของตารางเลย ถือว่าเป็นวิธีที่สะอาดและปลอดภัยที่สุดสำหรับฐานข้อมูลสายนี้

แต่สำหรับ MySQL นั้นต่างออกไปครับ MySQL ไม่มีคำสั่งแยกสำหรับใส่คำอธิบาย แต่เก็บมันไว้เป็น Attribute (คุณสมบัติ) หนึ่งของคอลัมน์ ซึ่งนั่นหมายความว่าหากคุณต้องการแก้ไขคำอธิบาย คุณต้องใช้คำสั่ง ALTER TABLE ... MODIFY เพื่อเขียนนิยามของคอลัมน์นั้นใหม่ทั้งหมด หากคุณเผลอใส่ข้อมูลไม่ครบถ้วน เช่น ลืมระบุประเภทข้อมูลหรือค่าเริ่มต้น ข้อมูลเหล่านั้นอาจหายไปได้ทันทีโดยไม่มีคำเตือน

-- ตัวอย่างการเพิ่มคำอธิบายใน PostgreSQL
COMMENT ON COLUMN invoices.voided_at IS 'บันทึกเวลาเมื่อฝ่ายการเงินยกเลิกใบแจ้งหนี้';

-- ตัวอย่างการเพิ่มคำอธิบายใน MySQL (ต้องเขียนใหม่ทั้งหมด)
ALTER TABLE invoices 
MODIFY COLUMN voided_at DATETIME COMMENT 'บันทึกเวลาเมื่อฝ่ายการเงินยกเลิกใบแจ้งหนี้';

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

วิธีแก้ปัญหา: ย้ายคำอธิบายออกจาก Database ไปไว้ที่ Model

หากการใส่คำอธิบายในฐานข้อมูลมันเสี่ยงและยุ่งยากเกินไป ทำไมเราไม่เก็บมันไว้ที่อื่นล่ะ? แนวทางที่นักพัฒนามืออาชีพหลายคนใช้คือการเก็บคำอธิบายไว้ใน ERD Tool (เครื่องมือออกแบบโครงสร้างฐานข้อมูล) หรือในไฟล์ Documentation ของโปรเจกต์แทนที่จะฝังลงไปใน Storage Engine (กลไกการจัดเก็บข้อมูลของฐานข้อมูล)

การเก็บคำอธิบายไว้ในโมเดลหรือแผนภาพ (Diagram) มีข้อดีมหาศาลครับ เพราะคุณสามารถแก้ไขคำอธิบายได้ตลอดเวลาโดยไม่ต้องกลัวว่าจะไปกระทบกับข้อมูลจริงใน Production นอกจากนี้ คุณยังสามารถทำ Version Control (การบันทึกประวัติการแก้ไขโค้ด) ผ่าน Git ได้เหมือนกับการเขียนโค้ดปกติ ทำให้ทีมงานทุกคนเห็นการเปลี่ยนแปลงได้ทันทีโดยไม่ต้องรัน Migration ใดๆ

วิธีนี้เปรียบเสมือนการทำ "คู่มือการใช้งาน" แยกต่างหากจากตัวเครื่องจักรครับ คุณสามารถอัปเดตคู่มือได้ทุกเมื่อโดยไม่ต้องหยุดเครื่องจักรหรือรื้อชิ้นส่วนภายในออกมา ซึ่งช่วยลดความเสี่ยงในการเกิด Downtime (ช่วงเวลาที่ระบบใช้งานไม่ได้) ได้อย่างมีประสิทธิภาพครับ

สรุป: เลือกวิธีที่เหมาะกับทีมและลดความเสี่ยง

การทำ Documentation เป็นหัวใจสำคัญของการทำงานเป็นทีม แต่การเลือกวิธีทำนั้นสำคัญพอๆ กัน หากคุณใช้ PostgreSQL และทีมมี Workflow ที่แข็งแรง การใช้ COMMENT ON ก็เป็นเรื่องที่ดี แต่ถ้าคุณใช้ MySQL หรือต้องการความคล่องตัวในการปรับปรุงเอกสารโดยไม่เสี่ยงต่อการทำข้อมูลพัง การย้ายคำอธิบายมาไว้ที่ Model หรือเครื่องมืออย่าง Schemity คือทางเลือกที่ฉลาดกว่า

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

1. หากคุณต้องเริ่มโปรเจกต์ใหม่ ให้เลือกใช้เครื่องมือออกแบบฐานข้อมูลที่รองรับการทำ Data Dictionary (พจนานุกรมข้อมูล) ในตัว
2. เขียนคำอธิบายคอลัมน์สำคัญ เช่น user_status หรือ payment_type ไว้ในเครื่องมือออกแบบนั้นๆ ตั้งแต่เริ่มออกแบบ
3. เมื่อเพื่อนในทีมถามว่าคอลัมน์นี้คืออะไร ให้ชี้ไปที่เอกสารใน Repository แทนการเปิด Database Console ดู
4. หากจำเป็นต้องใส่ใน Database จริงๆ ให้ทำเฉพาะคอลัมน์ที่จำเป็นที่สุดและผ่านการรีวิวจากทีมงานเสมอ

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

ที่มา: Column Comments in PostgreSQL and MySQL: How to Document Columns Without a Migration — DEV Community