Stored procedures คืออะไร และเมื่อใดควรใช้?

Question

Accepted Answer

**Stored procedure** คือชุดของคำสั่ง SQL (และ logic เชิงกระบวนการ) ที่บันทึกไว้ในฐานข้อมูลและดำเนินการด้วยชื่อ มันรัน logic *ภายใน* ฐานข้อมูลแทนที่จะอยู่ในโค้ดแอปพลิเคชัน มันมีประโยชน์ที่แท้จริงแต่ก็มีการแลกเปลี่ยนที่สำคัญด้วย ดังนั้นการตัดสินใจว่าเมื่อใดควรใช้จึงเป็นการตัดสินใจด้านการออกแบบที่แท้จริง

## Stored procedure

```sql
-- define a procedure that encapsulates logic in the database
CREATE PROCEDURE transfer_funds(from_id INT, to_id INT, amount DECIMAL)
LANGUAGE plpgsql AS $$
BEGIN
  UPDATE accounts SET balance = balance - amount WHERE id = from_id;
  UPDATE accounts SET balance = balance + amount WHERE id = to_id;
  -- can include logic: conditionals, loops, error handling, transactions
END;
$$;

CALL transfer_funds(1, 2, 100);   -- execute by name
```

Stored procedure รวม SQL และ logic เชิงกระบวนการ (ตัวแปร, conditionals, loops, การจัดการข้อผิดพลาด) เข้าเป็น routine ของฐานข้อมูลที่มีชื่อและนำกลับมาใช้ใหม่ได้ Functions คล้ายกันแต่คืนค่ากลับมา

## ประโยชน์ที่เป็นไปได้

```text
✓ Performance — runs IN the database (no round-trips for multi-step logic); precompiled
✓ Reduced network traffic — one call vs many queries from the app
✓ Reusability — shared logic callable from multiple applications/clients
✓ Security — grant EXECUTE on a procedure without granting table access; reduces
  injection surface (parameterized)
✓ Consistency — centralize critical logic so all clients use the same implementation
```

## การแลกเปลี่ยนที่สำคัญ (ทำไมหลายคนจึงหลีกเลี่ยงในปัจจุบัน)

```text
✗ Business logic in the DATABASE → harder to version-control, test, and maintain
  (logic split between app code and the database)
✗ Database-specific (PL/pgSQL vs T-SQL vs PL/SQL) → less portable, vendor lock-in
✗ Harder to debug than application code; weaker tooling
✗ Scaling — the database is often the hardest tier to scale; pushing logic there
  can increase its load
✗ Modern apps often prefer logic in the application layer (testable, portable, versioned)
```

## เมื่อใดควรใช้

```text
✓ Performance-critical data-intensive operations (heavy multi-step DB logic, batch jobs)
✓ Logic that MUST be enforced at the DB level across multiple clients
✓ Reducing round-trips for operations involving many queries
✗ AVOID putting general business logic in procedures by default — modern practice
  usually favors the application layer (better testing, versioning, portability)
```

## ทำไมจึงสำคัญ

การเข้าใจ stored procedures — รวมถึงการแลกเปลี่ยนของมัน — เป็นความรู้ที่มีคุณค่าเพราะมันแทนทางเลือกด้านสถาปัตยกรรมที่แท้จริงซึ่งมีทั้งประโยชน์และข้อเสียที่แท้จริง และการรู้ว่า *เมื่อใด* ควรใช้ (และเมื่อใดไม่ควร) สะท้อนถึงวิจารณญาณที่เป็นผู้ใหญ่

Stored procedures สามารถให้ **ประโยชน์ด้านประสิทธิภาพ** (การรัน logic หลายขั้นตอนภายในฐานข้อมูลหลีกเลี่ยง network round-trips), การลด network traffic, การนำกลับมาใช้ใหม่ข้าม client, ความปลอดภัย (การให้สิทธิ์ execute โดยไม่ต้องให้สิทธิ์เข้าถึงตาราง) และความสอดคล้องแบบรวมศูนย์ — ทำให้เหมาะสำหรับการดำเนินการที่เน้นข้อมูลและสำคัญต่อประสิทธิภาพ, การประมวลผลแบบ batch และ logic ที่ต้องบังคับใช้ที่ระดับฐานข้อมูลข้ามแอปพลิเคชันหลายตัว

อย่างไรก็ตาม การเข้าใจ **การแลกเปลี่ยนที่สำคัญ** ก็สำคัญพอ ๆ กันและสะท้อนถึงแนวปฏิบัติสมัยใหม่: การวาง business logic ในฐานข้อมูลทำให้ version-control, ทดสอบ และดูแลรักษายากขึ้น (แยก logic ระหว่างแอปและฐานข้อมูล), ผูกติดกับภาษาเชิงกระบวนการของฐานข้อมูลเฉพาะ (PL/pgSQL, T-SQL, PL/SQL — ลด portability), debug ยากกว่า และเพิ่มภาระให้กับ tier ของฐานข้อมูล (ซึ่งมักจะ scale ยากที่สุด)

ด้วยเหตุผลเหล่านี้ **การพัฒนาแอปพลิเคชันสมัยใหม่มักนิยมเก็บ business logic ไว้ในชั้นแอปพลิเคชัน** (ทดสอบได้, portable, version-controlled) มากกว่าใน stored procedures

ข้อมูลเชิงลึกหลักคือ **วิจารณญาณว่าเมื่อใดควรใช้** — เหมาะสำหรับความต้องการเฉพาะที่สำคัญต่อประสิทธิภาพหรือการบังคับใช้ที่ระดับฐานข้อมูล แต่โดยทั่วไปหลีกเลี่ยงเป็นค่าเริ่มต้นสำหรับ business logic

เนื่องจาก stored procedures พบได้บ่อยในหลายระบบ (โดยเฉพาะ enterprise/legacy) และเนื่องจากการเข้าใจทั้งประโยชน์และการแลกเปลี่ยน (และแนวโน้มสมัยใหม่ที่เอนไปทาง logic ในชั้นแอปพลิเคชัน) คือสิ่งที่ช่วยให้ตัดสินใจด้านสถาปัตยกรรมได้อย่างมีเหตุผล การเข้าใจ stored procedures จึงเป็นความรู้ระดับ senior ที่มีคุณค่าซึ่งแสดงถึงความสามารถในการชั่งน้ำหนัก logic ฝั่งฐานข้อมูลกับฝั่งแอปพลิเคชัน — เป็นข้อพิจารณาด้านการออกแบบที่มีความหมายและเป็นหัวข้อที่สะท้อนถึงวุฒิภาวะด้านสถาปัตยกรรม