ที่มา: http://www.narisa.com/blog/bomber/index.php?showentry=6
- เป็นบทความหลายปีแหละ แต่เห็นว่าค่อนข้างมีประโยชน์สำหรับตัวเอง
- ซึ่งยังไม่ค่อยทราบเหตุผลที่ต้องใช้ store procedure สักเท่าไหร่แต่ หลังๆ ใช้เกือบทุกงานเลยแฮะ
- ขอบคุณ คุณอาจารย์ bomber สำหรับบทความจากประสบการณ์ ดีๆ
หาก คิดถึง 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 ก็เป็นเรื่องที่ควรจะทำครับ
---------------------------------------------------------------------------------------
From: http://sqlblog.com/blogs/paul_nielsen/archive/2009/05/09/why-use-stored-procedures.aspx
Why use Stored Procedures?
There are as many opinions for and against using stored procedures as there are database-related roles. I believe the position that is most qualified to speak to stored procedures is the data architect’s role. Data architecture is the role that studies the various methods, patterns, standards, and best-practices that result in databases that will, together, best serve the organization now and in the future.
Don’t confuse data architecture with data modeling. Although data architects often do data modeling, data architecture and data modeling are different disciplines.
Data architecture evaluates various database designs and implementations by several criteria: e.g. usability, scalability, integrity, extensibility, security, and availability.
Of those six basic database criteria, there’s one that stands out as the most expensive to refactor or correct later: extensibility – the ability to modify the database to meet changing requirements. I’ve seen organizations with horrible database designs, that desperately need to re-develop that database, but they can’t. The database is so tightly coupled that the idea of making a slight change to the database brings management to its knees in fear. Dozens of applications, hundreds of reports, and a score of nightly ETL and maintenance tasks are tied directly to tables in the database. At one location, it takes a six person, highly qualified team six months to just modify a column. The result of tight coupling is a brittle database.
The cost of a brittle database is enormous to an organization. On the corporate roadmap, the database is the primary roadblock. The organization can’t implement critical changes because the database can’t support those changes. The organization (both internal clients and IT) will try to work around the brittle database with additional databases in an attempt to find features. IT will try to wrap the brittle database with additional layers in an attempt to find loose coupling. But complexity breeds complexity and eventually the organization with multiple completing database solutions will try to apply a master database so there’s a single source for answers. All this takes years and millions of dollars and… never… really… works.
The only real solution is an abstraction layer that fully encapsulates the database. Every database fetch, insert, and update must go through this access layer. Just as SOA provides this encapsulation for processes, the database needs the same black-box API. If the database team wants to refactor the database to improve some feature, it’s free to do so. If a new feature is added, the database team can add that feature and modify the API. It’s very clean, easy to refactor, and the database is now an on-ramp to the corporate roadmap.
If you can agree that a logical abstraction layer is required for database extensibility, the next question is, “Physically, where should the abstraction layer be implemented?”
Many will answer that it’s implemented in the programmer’s favorite language, and unfortunately that’s probably true.
A data architect would ask this probing question, “ What’s the projected life of the data?” When I teach my data architecture seminars, or give conference talks on data architecture, I ask the question, “How many of you have data that’s five years old?” every hand goes up. “Ten years old?” a few hands go down. This progresses until eventually one guy has data that 40-50 years old.
The point is: data has a long lifespan. If data has the lifespan of an elephant, then application languages have the lifespan of bugs. Think back just five years ago, what was the hot application language used to develop DAL layers? Ten years ago? Anybody up for writing a new web page that calls the COM+ DAL layer? Didn’t think so.
The data architect’s answer to why use stored procedures is that T-SQL is only language that you KNOW will last as long as the data. A stored procedure that was written ten years ago is still just as easy to call as one that will be written today, or in the future. Anything less is building a long term solution on today’s fad, and it’s just plain foolishness.
If you'd like to talk with me about this in person, I'll be at TechEd in LA this week, hanging out in the SQL Server pavilion.
No comments:
Post a Comment