ทำไมถึงต้องใช้ Stored Procedure

“ควรใช้ Stored Procedure หรือไม่?” เป็นคำถามที่ถกเถียงกันพอสมควรเวลาเริ่มต้นพัฒนา Application ใหม่ขึ้นมา

หากคิดถึง Application ที่อยู่ในลักษณะของ Vendor Software เนื่องจากเราไม่สามารถรู้ได้เลยว่า ลูกค้าจะใช้ DBMS ของเจ้าไหน ดังนั้น หากคุณเป็น Vendor และผลิต Software เพื่อขายแล้วละก็ไม่สมควรอย่างยิ่งที่จะใช้ Stored Procedure

แต่หากคุณไม่ใช่ Vendor และ Software ของคุณใช้แต่ในบริษัทของคุณแล้วละก็ คุณควรใช้ Stored Procedure อย่างที่สุด ทำไมนะเหรอ?

ตามประสบการณ์และมุมมองของผม คำตอบคือ ควรใช้ Stored Procedure ในการพัฒนา Application เพราะ

1. การแบ่งแยกการทำงานด้าน Data และ Business Logic อย่างชัดเจน : อย่างที่ทราบกันดีว่า Pattern ที่ได้รับความนิยมที่สุดในการพัฒนา Enterprise Application คือ Multi-Tier Application กล่าวคือการแยกการทำงานระหว่าง Presentation, Business Logic, และ Data อย่างชัดเจน

Business Logic คือ ส่วนการทำงานของ Application เป็นส่วนที่ควบคุม Flow การทำงานของ Application ว่าต้องทำอะไรก่อนอะไรหลัง เป็นส่วนที่ควบคุมเรื่อง Rule ต่างๆของ Process

Data คือส่วนการทำงานด้านการจัดเก็บ Data ต่างๆภายในระบบ รวมถึงการกำหนด Constraint ของ Data เรื่องของ Data Integrity และ Data Consistency ซึ่งสิ่งเหล่านี้เป็น Feature หลักๆที่สามารถทำได้โดยใช้ Store Procedure
ลองคิดดูหากคุณเอาคุณสมบัติในเรื่อง Data Integrity หรือ Data Consistency ไปใส่ใน Business Logic จะเหมาะสมหรือไม่? ใช่มันอาจจะทำได้ แต่หากมองถึงความเหมาะสมของเนื้องานและการแบ่งหน้าที่การทำงานในแง่ของทีมงานแล้วละก
็ มันไม่เหมาะสมเลยที่จะทำอย่างนั้น ดังนั้นนี่เป็นเหตุผลหลัก และประโยชน์ที่สำคัญของการใช้ Stored Procedure

2. การกระจาย Load การทำงาน : อีกเหตุผลหนึ่งของการใช้ Stored Procedure คือการแบ่ง Load การทำงานให้กระจายออกไปใน Network เป็น Concept หลักของการทำ Distributed System การใช้ Stored Procedure ก็เป็นส่วนสำคัญที่จะกระจาย Load การทำงานออกไป ไม่ให้หนักอยู่ที่ Business Logic เพียงที่เดียว

3. Transaction หรือ Single Unit of work : เป็นสิ่งสำคัญมากสำหรับเรื่อง Data Consistency เพราะ Data บางอย่างมีความสัมพันธ์กับอีก Data หนึ่ง ซึ่ง Stored Procedure เหมาะสมมากที่จะทำงานด้าน Transaction เพราะมันเป็น Feature หลักใน DBMS

อาจมีคนเถียงว่า Business Logic ก็สามารถทำงานด้านนี้ได้เหมือนกัน แต่ลองคิดดูดีๆนะครับว่า Application ที่ใช้ทำ Business Logic เช่น J2EE หรือ .NET เองจะมี Feature ด้าน Transaction สู้ Oracle หรือ MS SQL ได้หรือไม่ ทั้งในแง่ของ Performance และ Function การทำงาน

4. ความคุ้มค่า : คือ RDBMS ที่บริษัทคุณซื้อมา และ Server ที่ Host อยู่นั้น ราคาไม่ถูกเลย ลองคิดดูว่าราคาที่คุณลงทุนลงไป 100% แต่กลับใช้งาน Feature ของมันเพียง 20% คุ้มค่าหรือไม่ ในแง่ของการลงทุนแล้วเห็นชัดเจนว่าไม่คุ้มค่าแม้แต่นิดเดียว หากคุณคิดจะใช้ RDBMS ราคาแพงอย่าง Oracle หรือ MS SQL แล้วละก็ คุณก็ควรจะพิจารณาถึง Feature ต่างๆที่มันมีให้และใช้มันอย่างคุ้มค่า ไม่เพียงแต่ Stored Procedure เท่านั้น ไม่ว่าจะเป็น Trigger, View, Job คุณก็ควรจะใช้ทุกๆ Feature ที่สามารถนำไปประยุกต์กับงานของคุณได้

สิ่งที่หลายๆคนกลัวคือ หากวันใดเกิดมาการเปลี่ยน Software ที่ใช้ทำ RDBMS จะต้องมีการแก้ Code มากๆมาย เพราะแต่ละเจ้าก็มันจะใช้ภาษา SQL ที่มีความแตกต่างกัน แต่ผมถามจริงๆเถอะ คุณเปลี่ยน RDBMS ทุกวันหรือเปล่า? ที่จริงแล้วมีโอกาศเปลี่ยนมากแค่ไหน? ลองคิดดูดีๆนะครับ การเปลี่ยน Software ของ RDBMS ไม่ใช่เรื่องเล็กๆ คุณแถบไม่ต้องกังวลเรื่องนี้เลย เพราะปกติแล้วหากบริษัทเรื่องใช้ RDBMS เจ้าไหนแล้วละก็ โอกาศที่คิดจะเปลี่ยนนั้นไม่เกิน 10% แน่นอน

ซึ่งเทียบกันแล้วมองอย่างไรการใช้ Stored Procedure เพื่อช่วยในการพัฒนา Enterprise Application ก็เป็นเรื่องที่ควรจะทำครับ

credit : http://www.narisa.com/blog/bomber/index.php?showentry=6