ในฐานะผู้ดูแลระบบและนักวางกลยุทธ์เนื้อหา การรักษาความสม่ำเสมอในการเผยแพร่ (Content Consistency) เป็นสิ่งสำคัญอย่างยิ่ง โดยเฉพาะอย่างยิ่งเมื่อคุณมีตารางการโพสต์ที่กำหนดไว้ เช่น การโพสต์ทุกวันเสาร์ แต่ด้วยความเร่งรีบในการทำงาน อาจมีบางครั้งที่การตั้งเวลาเผยแพร่เกิดความผิดพลาด
หากคุณต้องการตรวจสอบฐานข้อมูล WordPress ว่ามีโพสต์ใดบ้างที่ไม่ได้เผยแพร่ในวันเสาร์ตามตารางที่วางไว้ การใช้คำสั่ง SQL ที่ถูกต้องและเจาะจงจึงเป็นสิ่งจำเป็น บทความนี้จะแนะนำวิธีการเขียน Query เพื่อตรวจสอบความสม่ำเสมอของโพสต์เหล่านั้น โดยเน้นการใช้ไวยากรณ์ของ PostgreSQL ซึ่งเป็นระบบฐานข้อมูลที่ทรงพลังและมีความแม่นยำสูง
🛠️ หลักการทำงาน: การค้นหาความผิดปกติของวันเผยแพร่
เป้าหมายของเราคือการดึงรายการโพสต์ทั้งหมดที่สถานะเป็น ‘เผยแพร่’ (publish) หรือ ‘กำลังจะมาถึง’ (future) แต่มีวันเผยแพร่ที่ไม่ใช่วันเสาร์
SQL
SELECT ID, post_date, post_title, <0xC2><0xA0>-- ใช้ TO_CHAR เพื่อแสดงชื่อวันเป็นภาษาไทย<br>TO_CHAR(post_date, 'Day') AS day_name_th<br>FROM wp_posts<br>WHERE post_type = 'post' AND post_status IN ('publish', 'future')<br>-- เงื่อนไขหลัก: ตรวจสอบว่าวันของสัปดาห์ (DOW) ไม่เท่ากับวันเสาร์ (6)<br>AND EXTRACT(DOW FROM post_date) <> 6<br>ORDER BY post_date ASC;
💡 คำอธิบายโค้ด PostgreSQL (Technical Deep Dive)
การเขียน Query นี้อาศัยฟังก์ชันเฉพาะของ PostgreSQL เพื่อให้ได้ผลลัพธ์ที่แม่นยำ:
EXTRACT(DOW FROM post_date): นี่คือหัวใจหลักของคำสั่งนี้ครับ ใน PostgreSQL,EXTRACT(DOW FROM date)จะดึงค่าตัวเลขของวันในสัปดาห์ออกมา โดยที่ 0 คือวันอาทิตย์ และ 6 คือวันเสาร์ ดังนั้น การใช้<> 6จึงเป็นการสั่งให้ระบบดึงเฉพาะโพสต์ที่ไม่ได้ถูกตั้งเวลาเผยแพร่ในวันเสาร์เท่านั้นTO_CHAR(post_date, 'Day'): ฟังก์ชันนี้ช่วยแปลงค่าวันที่ให้เป็นรูปแบบข้อความที่อ่านง่ายขึ้น เพื่อให้ผู้ใช้งานสามารถตรวจสอบได้ทันทีว่าโพสต์นั้นอยู่ในวันอะไรpost_status IN ('publish', 'future'): เป็นการจำกัดขอบเขตให้ Query ดึงเฉพาะโพสต์ที่มีสถานะเผยแพร่แล้ว หรือโพสต์ที่ถูกตั้งเวลาไว้ในอนาคตเท่านั้น
✅ บทสรุปและข้อควรระวัง
เมื่อรัน Query นี้แล้ว ผลลัพธ์ที่ได้คือรายการโพสต์ทั้งหมดที่ ‘ผิดปกติ’ คือโพสต์ที่ไม่ได้เผยแพร่ในวันเสาร์ตามตารางที่วางไว้ คุณสามารถนำรายการ ID เหล่านี้ไปตรวจสอบและแก้ไขวันที่เผยแพร่ให้ถูกต้องได้ทันที
ข้อควรระวังระดับ Senior Architect: ก่อนรัน Query ใดๆ กับ Production Database ควรทำการสำรองข้อมูล (Database Backup) เสมอ และควรทดสอบ Query นี้ในสภาพแวดล้อม Staging ก่อนเสมอ เพื่อป้องกันการรบกวนข้อมูลจริง