ป้ายกำกับ: Cte

ในฐานะ System Specialist และ Senior Database Architect การจัดการกับข้อมูลสตริง (String Manipulation) อย่างแม่นยำและมีประสิทธิภาพถือเป็นหัวใจสำคัญของการออกแบบระบบฐานข้อมูลที่แข็งแกร่ง เมื่อเราต้องทำการตรวจสอบว่าค่าใดค่าหนึ่งในคอลัมน์ของตารางนั้น ๆ เริ่มต้นด้วย หรือ ลงท้ายด้วย ข้อความส่วนใดส่วนหนึ่งหรือไม่ การใช้ไวยากรณ์ SQL ที่เหมาะสมจึงเป็นสิ่งจำเป็น

ในโลกของ PostgreSQL เราไม่ได้มีฟังก์ชันที่ชื่อว่า str_starts_with() หรือ str_ends_with() โดยตรงเหมือนภาษา PHP แต่เราสามารถบรรลุผลลัพธ์เดียวกันได้อย่างทรงพลังและมีประสิทธิภาพสูงผ่านการใช้ตัวดำเนินการ (Operator) และรูปแบบการจับคู่สตริง (Pattern Matching) ที่เป็นมาตรฐานของ SQL นั่นคือ LIKE ร่วมกับ Wildcard Character %

หลักการเปรียบเทียบ Prefix และ Suffix ใน PostgreSQL

หัวใจของการตรวจสอบนี้คือความเข้าใจในตัวดำเนินการ LIKE ซึ่งเป็นเครื่องมือที่ทรงพลังที่สุดในการค้นหาข้อมูลตามรูปแบบ (Pattern Matching) โดยมีหลักการดังนี้:

• Prefix Check (เริ่มต้นด้วย): หากต้องการตรวจสอบว่าคอลัมน์ชื่อ document_name เริ่มต้นด้วยคำว่า ‘report’ เราจะใช้ไวยากรณ์ WHERE document_name LIKE 'report%' เครื่องหมายเปอร์เซ็นต์ (%) ที่อยู่หลังข้อความคือ Wildcard ที่แทนอักขระใด ๆ ได้จำนวนเท่าใดก็ได้
• Suffix Check (ลงท้ายด้วย): หากต้องการตรวจสอบว่าคอลัมน์ document_name ลงท้ายด้วยนามสกุล ‘.pdf’ เราจะใช้ไวยากรณ์ WHERE document_name LIKE '%report.pdf' เครื่องหมายเปอร์เซ็นต์ (%) ที่อยู่หน้าข้อความคือ Wildcard ที่แทนอักขระใด ๆ ได้จำนวนเท่าใดก็ได้

การใช้รูปแบบ LIKE นี้ไม่เพียงแต่ช่วยให้โค้ดของเรามีความกระชับและอ่านง่ายขึ้นเท่านั้น แต่ยังเป็นการใช้ Built-in Function ของ PostgreSQL ที่ได้รับการ Optimize มาแล้วในระดับ C ทำให้มีประสิทธิภาพสูงในการจัดการข้อมูลขนาดใหญ่

ตัวอย่างการใช้งานเชิงลึกด้วย CTE และ Pattern Matching

ตัวอย่างโค้ดด้านล่างนี้แสดงให้เห็นถึงการจำลองสถานการณ์การตรวจสอบไฟล์เอกสาร โดยใช้ Common Table Expression (CTE) เพื่อสร้างชุดข้อมูลสมมติ และทำการกรองข้อมูลที่ตรงตามเงื่อนไข Prefix หรือ Suffix ที่กำหนด

WITH documents AS (
    SELECT 'report_2024_q3.pdf' AS document_name,
           'https://api/v1/' AS source_url
    UNION ALL
    SELECT 'image_profile.jpg', 
           'http://cdn.example.com'
    UNION ALL
    SELECT 'data_summary_2023.csv', 
           'ftp://backup.server/'
) 
SELECT 
    document_name,
    source_url,
    CASE WHEN document_name LIKE 'report%' THEN '✅ Prefix Match (Report)' ELSE '❌ No Prefix Match' END AS prefix_check,
    CASE WHEN document_name LIKE '%.pdf' THEN '✅ Suffix Match (.pdf)' ELSE '❌ No Suffix Match' END AS suffix_check
FROM documents
WHERE 
    (document_name LIKE 'report%') OR (document_name LIKE '%.pdf');

ข้อควรระวังด้านประสิทธิภาพและการออกแบบฐานข้อมูล

ในฐานะ Senior Architect สิ่งที่สำคัญกว่าการเขียนโค้ดให้ทำงานได้คือการทำให้มันทำงานได้อย่างรวดเร็วและปลอดภัย:

• Indexing: การใช้ LIKE '%suffix' (Wildcard ที่อยู่หน้าสุด) จะทำให้ PostgreSQL ไม่สามารถใช้ B-tree Index ได้อย่างเต็มที่ เนื่องจากต้องสแกนข้อมูลทั้งหมด (Full Table Scan) หากคุณทราบว่าส่วนย่อยจะอยู่ที่จุดเริ่มต้นเสมอ ควรสร้าง Index แบบ Standard เพื่อประสิทธิภาพสูงสุด
• Performance Optimization: สำหรับการตรวจสอบ Prefix ที่มีประสิทธิภาพสูงที่สุด ให้หลีกเลี่ยงการใช้ LIKE และพิจารณาใช้ฟังก์ชันเฉพาะทาง เช่น SUBSTR(column, 1, length) หรือสร้าง Index แบบ Trigram (using the pg_trgm extension) หากคุณต้องค้นหาแบบ Fuzzy Search
• Security: เมื่อค่าที่นำมาตรวจสอบมาจาก Input ของผู้ใช้งาน ควรใช้ Parameterized Queries เสมอ เพื่อป้องกัน SQL Injection ไม่ว่าจะเป็นการตรวจสอบ Prefix/Suffix ก็ตาม

โดยสรุปแล้ว การทำความเข้าใจและใช้ประโยชน์จากตัวดำเนินการ LIKE ร่วมกับ Wildcard % คือวิธีมาตรฐานและมีประสิทธิภาพสูงสุดในการจำลองฟังก์ชันการเปรียบเทียบสตริง Prefix และ Suffix ใน PostgreSQL ทำให้โค้ดของเรามีความสามารถในการอ่าน (Readability) สูง และยังคงรักษาความเร็วระดับ Production ได้อย่างยอดเยี่ยม