Day 14: Architectural Trade-offs & Anti-patterns Summary (การวิเคราะห์ข้อดี-ข้อเสียเชิงเปรียบเทียบ, การรวบรวม Anti-patterns ต้องห้าม, ปัญหา Cascading Triggers, และช่องโหว่ Unsanitized Dynamic SQL Injection)

ในการเป็น Software Architect หรือ Senior Engineer สิ่งที่อันตรายที่สุดไม่ใช่การไม่รู้เทคโนโลยี แต่คือ "การมองเห็นแต่ข้อดีจนมองข้ามข้อเสียและจุดตาย (Architectural Blind Spots)" In-Database Automation Engine มอบพลังความเร็วระดับ Sub-millisecond และ Data Integrity สูงสุด แต่หากขาดการกำกับดูแลเชิงสถาปัตยกรรม (Architectural Governance) โค้ดที่รวดเร็วในวันแรกจะกลายเป็น Maintenance Nightmare และช่องโหว่ความปลอดภัยระดับพันล้านในวันถัดไป!

⚖️ แม่บทดรรชนีการแลกเปลี่ยนเชิงสถาปัตยกรรม (Architectural Trade-offs Matrix)

การเขียน Dynamic SQL ใน PL/pgSQL มีความจำเป็นในกรณีที่ต้องการสร้างคำสั่งค้นหาแบบยืดหยุ่น หรือเลือกตารางเป้าหมายแบบไดนามิก แต่การนำตัวแปรมาต่อ String ด้วย || คือช่องโหว่ความปลอดภัยระดับร้ายแรงที่สุด มาดูโครงสร้างที่ถูกต้องเพื่อปิดช่องโหว่นี้ 100%:

-- ❌ UNSAFE Dynamic SQL (เสี่ยง SQL Injection 100%):
EXECUTE 'SELECT * FROM ' || v_table_name || ' WHERE status = ''' || v_status || '''';

-- ✅ SECURE Dynamic SQL (ปลอดภัยระดับ Enterprise):
EXECUTE format('SELECT * FROM %I WHERE status = $1', v_table_name)
   USING v_status;

-- 🎯 ถอดรหัสหัวใจสำคัญ 2 ประการ:
-- [1] %I ใน format(): สำหรับ Sanitizing "Identifier" (ชื่อตาราง / ชื่อคอลัมน์ / ชื่อ Schema)
-- [2] $1 ร่วมกับ USING: สำหรับส่ง "Value / Parameter" เข้าไปแบบ Parameterized Query (ป้องกัน SQL Injection)

🏋️‍♂️ แบบฝึกหัดไต่ระดับการเขียนจริง (จากระดับเริ่มต้น ➔ Secure Production Architecture)

-- ❌ ตัวอย่างโค้ดที่เป็น Cascading Trigger Anti-pattern:
-- [Trigger 1 บนตาราง orders]
CREATE OR REPLACE FUNCTION fn_trg_orders_after_update() RETURNS TRIGGER LANGUAGE plpgsql AS $$
BEGIN
    -- เมื่อมีออเดอร์ใหม่ สั่ง UPDATE ตาราง inventory ต่อไป
    UPDATE inventory SET stock = stock - 1 WHERE product_id = NEW.product_id;
    RETURN NULL;
END $$;

-- [Trigger 2 บนตาราง inventory]
CREATE OR REPLACE FUNCTION fn_trg_inventory_after_update() RETURNS TRIGGER LANGUAGE plpgsql AS $$
BEGIN
    -- เมื่อสต็อกเปลี่ยน สั่ง UPDATE ตาราง supplier_orders ต่อไปอีก!
    UPDATE supplier_orders SET auto_refill = TRUE WHERE product_id = NEW.product_id;
    RETURN NULL;
END $$;

-- 🎯 ผลลัพธ์: เกิด Chain Reaction ที่ไม่สามารถควบคุมได้ เมื่อมี Concurrency สูง จะเกิด Deadlock Cascade ทันที!
-- ✅ แนวทางแก้: ยกเลิก Trigger ซ้อนทับ แล้วรวมการทำงานทั้ง 3 ขั้นตอนไว้ใน Stored Procedure เดียวอย่างโปร่งใส!

-- db/migration/R__01_secure_dynamic_search.sql
-- 🎯 ป้องกัน SQL Injection 100% บนการค้นหาแบบ Dynamic Table
CREATE OR REPLACE FUNCTION fn_secure_dynamic_count(
    p_table_name VARCHAR,
    p_status     VARCHAR
)
RETURNS BIGINT
LANGUAGE plpgsql
STABLE
AS $$
DECLARE
    v_count BIGINT;
    v_sql   TEXT;
BEGIN
    -- [บรรทัดที่ 1] สร้าง Dynamic Query โดยใช้ %I สำหรับชื่อตาราง และ $1 สำหรับตัวแปร
    v_sql := format('SELECT count(*) FROM %I WHERE status = $1', p_table_name);

    -- [บรรทัดที่ 2] รันคำสั่งด้วย EXECUTE และส่งค่า p_status เข้าไปยัง $1 ผ่าน USING
    EXECUTE v_sql INTO v_count USING p_status;

    RETURN v_count;
END $$;

-- ตัวอย่างการเรียกใช้งาน:
-- SELECT fn_secure_dynamic_count('accounts', 'ACTIVE');

🔴 Level 3: Refactoring Flawed Code (Unsanitized Dynamic SQL ➔ Production-Grade Parametric Architecture)

เปรียบเทียบโค้ดเดิมที่มีช่องโหว่ SQL Injection ร้ายแรง และฮาร์ดโค้ดอัตราภาษี กับโค้ดใหม่ระดับ Enterprise ที่ปิดช่องโหว่ความปลอดภัยและยืดหยุ่นต่อการดูแลรักษา:

-- ❌ Flawed Code: ต่อ String ด้วย || เปิดช่องโหว่ SQL Injection ทันที!
CREATE OR REPLACE FUNCTION fn_get_user_report_flawed(
    p_schema_name TEXT,
    p_user_role TEXT
)
RETURNS TABLE(user_id BIGINT, username TEXT)
LANGUAGE plpgsql
AS $$
DECLARE
    v_query TEXT;
BEGIN
    -- ❌ ช่องโหว่ร้ายแรง #1: เอาพารามิเตอร์มาต่อ String ตรงๆ
    -- ❌ ช่องโหว่ #2: ฮาร์ดโค้ดอัตราภาษี 0.07 ลงในโค้ดตรงๆ (Magic Number)
    v_query := 'SELECT id, name FROM ' || p_schema_name || 
               '.users WHERE role = ''' || p_user_role || 
               ''' AND tax_rate = 0.07';

    RETURN QUERY EXECUTE v_query;
END $$;

-- db/migration/R__02_get_user_report_secure.sql
-- 🎯 ปิดช่องโหว่ SQL Injection 100% ด้วย format(%I, %I) และใช้ USING ส่งตัวแปร

CREATE OR REPLACE FUNCTION fn_get_user_report_secure(
    p_schema_name VARCHAR,
    p_user_role   VARCHAR
)
RETURNS TABLE(user_id BIGINT, username VARCHAR)
LANGUAGE plpgsql
STABLE
AS $$
DECLARE
    v_query    TEXT;
    v_tax_rate NUMERIC;
BEGIN
    -- [บรรทัดที่ 1] ดึงค่า Config ทางธุรกิจจากตารางแทนการ Hardcode
    SELECT config_value::numeric INTO v_tax_rate
    FROM system_configurations
    WHERE config_key = 'VAT_RATE';

    -- [บรรทัดที่ 2] ใช้ format() กับ %I เพื่อซานิไทซ์ Schema และ Table Identifiers
    v_query := format(
        'SELECT id, name FROM %I.users WHERE role = $1 AND tax_rate = $2',
        p_schema_name
    );

    -- [บรรทัดที่ 3] ใช้ RETURN QUERY EXECUTE ร่วมกับ USING เพื่อส่งตัวแปรเข้า $1 และ $2
    RETURN QUERY EXECUTE v_query USING p_user_role, v_tax_rate;
END $$;

แบบทดสอบวัดระดับความเข้าใจ Day 14: Architectural Trade-offs & Anti-patterns Summary (Vendor Lock-in, Cascading Triggers, Dynamic SQL Sanitization, Hardcoded Magic Numbers) และข้อสอบสะสมทบทวนครบทั้ง Days 1–13 คลิกเลือกคำตอบ ก, ข, ค, หรือ ง เพื่อดูผลลัพธ์และคำอธิบายอย่างละเอียดทันที

🎉 ยินดีด้วยครับ! คุณได้ผ่าน Phase 3 (DevOps, Maintainability & Architectural Boundaries) ครบถ้วนแล้ว!

บทเรียน Day 14: Architectural Trade-offs & Anti-patterns Summary ได้ทำหน้าที่รวบยอดและสรุปภาพรวมเชิงสถาปัตยกรรมของ Phase 3 ทั้งหมด โดยการทำความเข้าใจข้อแลกเปลี่ยน (Trade-offs) ระหว่างความเร็วในการประมวลผลกับ Vendor Lock-in และการกำหนดกฎเหล็กเพื่อป้องกัน Anti-patterns ร้ายแรง เช่น Cascading Triggers และ Unsanitized Dynamic SQL Injection ซึ่งช่วยให้สถาปนิกและนักพัฒนามีหลักยึดที่มั่นคงในการออกแบบระบบ Enterprise