ควรใช้งาน Stored procedure ใน database หรือไม่ ?

เพิ่งคุยเรื่องการใช้งาน Stored procedure ที่เขียนใน database
ว่าระบบ legacy หลาย ๆ ตัวใช้งานกัน
และยังคงดูแลรักษา เพิ่ม feature ต่าง ๆ มาจนถึงปัจจุบัน
ตลอดจนก็สรรเสริญถึงมันเยอะมาก ๆ !!
ว่าแต่ปัญหามันคืออะไรกันแน่ ?
มันไม่ดีใช่ไหม ?

ก่อนอื่นต้องมาดูข้อดีของ Stored procedure ก่อนว่ามีอะไรบ้าง

เนื่องจากถ้ามันไม่ดีแล้ว จะมีใน database ต่าง ๆ ทำไมกัน
ข้อดีมีดังนี้

• ความเร็วในการจัดการข้อมูลที่สูงมาก ๆ เพราะว่าไม่ต้องส่งข้อมูลข้ามระบบ network ดังนั้น network latency น้อยมาก ๆ
• ง่ายต่อการจัดการ เพราะว่า อยู่ที่เดียวคือ database
• ซ่อนการทำงานต่าง ๆ จากผู้ใช้งาน เราสามารถซ่อนความซับซ้อนได้ง่าย ๆ คนใช้งานก็ง่าย
• สามารถใช้งานความสามารถอื่น ๆ ของ database ได้ง่าย

แต่ปัญหาที่มักเกิดขึ้นคือ

• นำ business logic, validation, logging, traction ของระบบที่ซับซ้อน ไปใส่ไว้ใน stored procedure มันสามารถทำได้ แต่การดูแลไม่ง่ายเลย
• แต่ละ stored procedure ทำการเรียก stored procedure อื่น ๆ ไปมา ทำให้แก้ไขที่หนึ่ง ดันไปกระทบอีกที่หนึ่ง
• การจัดการ versioning ของ store procedure ยาก
• เจอระบบแบบกระจายตามแต่ละ business/service ยิ่งลำบาก รวมถึงการจัดการ transaction
• การทดสอบไม่ต้องพูดถึง ไม่ง่ายเลย
• เกิดการ lock กับ database นั้น ๆ ทำให้เปลี่ยน หรือ scale ได้ยาก
• ขาดคนที่มีความรู้และเข้าใจกับ database และ stored procedure ทำให้ค่าใช้จ่ายในการดูแลรักษาสูงขึ้น

ดังนั้น อย่าไปเขียน business logic ไว้ใน stored procedure จะดีกว่า
ไม่ใช่ว่า ไม่ใช้เลย ซึ่งก็ไม่ถูกต้อง
ยิ่งถ้าเป็นการทำงานกับระบบที่รวม database ไว้ด้วยกัน
stored procedure จะเหมาะสมมาก ๆ ในการจัดการ เช่น ETL (Extract, Transform, Loader)

ดังนั้นสิ่งต่าง ๆ เหล่านี้มันคือ การตัดสินใจ

ซึ่งเริ่มต้นมันอาจจะดี
แต่เมื่อเวลาผ่านไป
ความต้องการเปลี่ยน
technology เปลี่ยน
ดังนั้นสิ่งที่เราเคยทำไป หรือ ตัดสินใจลงไป อาจจะผิดหรือไม่เหมาะสมได้
ดังนั้นสิ่งที่ควรทำคือ การปรับปรุง และ เปลี่ยนตั้งแต่เนิ่น ๆ
มิใช่ปล่อยไว้จนเป็นภาระ ต่อคนดูแลระบบ
และสุดท้ายมันก็ส่งผลต่อ business แบบหลีกเลี่ยงไม่ได้เลย