View คืออะไร?

View คืออะไร?

ในโลกของฐานข้อมูล MySQL, View เปรียบเสมือน "ตารางเสมือน" ที่ไม่ได้เก็บข้อมูลจริง แต่สร้างขึ้นจากผลลัพธ์ของ Query ที่ถูกบันทึกไว้ เมื่อเราเรียกใช้ View, MySQL จะรัน Query ที่ถูกบันทึกไว้และแสดงผลลัพธ์ออกมา เหมือนกับว่าเรากำลังเรียกใช้ตารางจริงๆ

Query ที่ถูกบันทึก

หัวใจสำคัญของ View คือการเป็น Query ที่ถูกบันทึกไว้ นั่นหมายความว่า View จะเก็บ Query `SELECT` ที่ซับซ้อน ซึ่งอาจเกี่ยวข้องกับการ JOIN หลายตาราง, การใช้ฟังก์ชัน aggregate (เช่น COUNT(), SUM(), AVG()), หรือการใช้ Clause ต่างๆ เช่น WHERE, GROUP BY, HAVING เมื่อเราสร้าง View, เรากำลังบันทึก Query เหล่านั้นไว้ในฐานข้อมูล

ตัวอย่าง: สมมติว่าเรามีฐานข้อมูลสำหรับร้านค้าออนไลน์ ซึ่งมีตาราง customers (ข้อมูลลูกค้า) และตาราง orders (ข้อมูลการสั่งซื้อ) เราต้องการ View ที่แสดงชื่อลูกค้าและจำนวนการสั่งซื้อทั้งหมดของลูกค้าแต่ละคน Query สำหรับสิ่งนี้อาจเป็น:

SELECT
    c.customer_id,
    c.customer_name,
    COUNT(o.order_id) AS total_orders
FROM
    customers c
LEFT JOIN
    orders o ON c.customer_id = o.customer_id
GROUP BY
    c.customer_id, c.customer_name;

เราสามารถสร้าง View จาก Query นี้ได้ และเมื่อเราเรียกใช้ View, เราจะได้ผลลัพธ์เหมือนกับการรัน Query ข้างต้น

ช่วยลดความซับซ้อน

ประโยชน์หลักอย่างหนึ่งของ View คือการลดความซับซ้อนของ Query ที่ต้องใช้บ่อยๆ แทนที่จะต้องเขียน Query ที่ซับซ้อนซ้ำๆ ทุกครั้ง, เราสามารถสร้าง View เพียงครั้งเดียว และเรียกใช้ View นั้นได้ทุกเมื่อที่ต้องการ

เหตุผลเชิงออกแบบและ Trade-offs:

• Readability: View ช่วยให้ Query หลักของเราสั้นและเข้าใจง่ายขึ้น เนื่องจากความซับซ้อนถูกซ่อนไว้ใน View
• Maintainability: หากโครงสร้างของตารางพื้นฐานเปลี่ยนแปลง, เราสามารถแก้ไข View เพื่อให้ยังคงให้ผลลัพธ์ที่ถูกต้อง โดยไม่ต้องแก้ไข Query ที่เรียกใช้ View
• Performance: View ไม่ได้ปรับปรุงประสิทธิภาพโดยอัตโนมัติ การเรียกใช้ View ยังคงต้องรัน Query ที่ถูกบันทึกไว้ อย่างไรก็ตาม, การใช้ View สามารถช่วยให้ Optimizer ของ MySQL ทำงานได้ดีขึ้นในบางกรณี
• Overhead: การสร้าง View จำนวนมากเกินไป อาจทำให้เกิด overhead ในการจัดการ metadata ของ View

ตัวอย่าง: พิจารณา Query ที่ซับซ้อนที่ใช้ JOIN หลายตารางและคำนวณค่าต่างๆ:

SELECT
    p.product_name,
    SUM(oi.quantity * p.price) AS total_revenue
FROM
    products p
JOIN
    order_items oi ON p.product_id = oi.product_id
JOIN
    orders o ON oi.order_id = o.order_id
WHERE
    o.order_date BETWEEN '2023-01-01' AND '2023-12-31'
GROUP BY
    p.product_name
ORDER BY
    total_revenue DESC
LIMIT 10;

ถ้าเราต้องใช้ Query นี้บ่อยๆ, การสร้าง View จะช่วยลดความซับซ้อนได้มาก:

CREATE VIEW top_10_products_revenue AS
SELECT
    p.product_name,
    SUM(oi.quantity * p.price) AS total_revenue
FROM
    products p
JOIN
    order_items oi ON p.product_id = oi.product_id
JOIN
    orders o ON oi.order_id = o.order_id
WHERE
    o.order_date BETWEEN '2023-01-01' AND '2023-12-31'
GROUP BY
    p.product_name
ORDER BY
    total_revenue DESC
LIMIT 10;

จากนั้นเราสามารถเรียกใช้ View ได้ง่ายๆ:

SELECT * FROM top_10_products_revenue;

Security

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

เหตุผลเชิงออกแบบและ Trade-offs:

• Data Masking: View สามารถใช้เพื่อ Mask ข้อมูลที่ละเอียดอ่อน เช่น หมายเลขบัตรเครดิต หรือที่อยู่ โดยการแสดงเฉพาะส่วนที่จำเป็นเท่านั้น
• Row-Level Security: View สามารถใช้เพื่อกรองข้อมูลที่ผู้ใช้สามารถมองเห็นได้ โดยขึ้นอยู่กับบทบาทหรือสิทธิ์ของผู้ใช้
• Complexity: การใช้ View เพื่อความปลอดภัยอาจเพิ่มความซับซ้อนให้กับระบบ
• Performance: View ที่ใช้เพื่อความปลอดภัยอาจทำให้ Query ช้าลง เนื่องจากต้องมีการกรองข้อมูลเพิ่มเติม

ตัวอย่าง: สมมติว่าเรามีตาราง employees ที่เก็บข้อมูลเงินเดือนของพนักงาน เราไม่ต้องการให้พนักงานทั่วไปสามารถเห็นข้อมูลเงินเดือนของพนักงานคนอื่นได้ เราสามารถสร้าง View ที่แสดงเฉพาะข้อมูลที่ไม่เกี่ยวข้องกับเงินเดือน:

CREATE VIEW employee_info AS
SELECT
    employee_id,
    employee_name,
    department,
    email
FROM
    employees;

จากนั้นเราสามารถให้สิทธิ์การเข้าถึง View นี้แก่พนักงานทั่วไป โดยไม่ให้สิทธิ์การเข้าถึงตาราง employees โดยตรง

แนวปฏิบัติที่ดี

• ตั้งชื่อ View ให้สื่อความหมาย: ชื่อ View ควรบ่งบอกถึงวัตถุประสงค์ของ View อย่างชัดเจน
• หลีกเลี่ยงการสร้าง View ที่ซับซ้อนเกินไป: View ที่ซับซ้อนเกินไปอาจทำให้ยากต่อการบำรุงรักษาและอาจส่งผลเสียต่อประสิทธิภาพ
• ใช้ View เพื่อลดความซับซ้อนของ Query ที่ต้องใช้บ่อยๆ: View ควรถูกนำมาใช้เพื่อลดความซับซ้อนของ Query ที่ซับซ้อนและถูกใช้งานบ่อยๆ
• พิจารณาผลกระทบต่อประสิทธิภาพ: ก่อนที่จะสร้าง View, ควรพิจารณาผลกระทบต่อประสิทธิภาพของ Query ที่เรียกใช้ View
• ตรวจสอบสิทธิ์การเข้าถึง View: ตรวจสอบให้แน่ใจว่าผู้ใช้มีสิทธิ์การเข้าถึง View ที่เหมาะสม

ในบทต่อไป เราจะเรียนรู้วิธีการสร้าง View ใน MySQL โดยใช้คำสั่ง CREATE VIEW