Store Procedure là tập hợp các câu lệnh SQL đã được biên dịch và lưu trữ dưới một tên riêng và được SQL xử lý như một đơn vị
SP chứa các phép toán, các câu lệnh xử lý, lệnh điều kiện.....
Qui tắc viết: CREATE PROCEDURE <ten_thu_tuc> [Khai báo các tham số đầu vào, đầu ra] AS [Phần lệnh thủ tục] GO
Một ứng dụng tốt phải đảm bảo được các yếu tố: usability, scalability, integrity, extensibility, security, và availability. Trong đó extensibility là một yếu tố tương đối quan trọng (nếu như bạn không muốn sau này phải làm lại một ứng dụng mới).
Nhiều người cho rằng Store Procedure có vai trò như database-related, một số khác lại cho rằng nó có vai trò như data architecture. Các data architect cũng gần giống như các data modeling. Tôi thì không quan tâm mấy đến những sự khác biệt này mà chỉ đưa ra cho bạn thấy một trong nhiều trường hợp cụ thể để giải thích tại sao lại dùng Store Procedure:
Ví dụ bạn có 1 website hoặc ứng dụng có truy vấn CSDL. Và khi code, bạn đã viết rất nhiều câu truy vấn khác nhau. Giả sử sau này muốn thêm một field dữ liệu mới vào một table nào đó thì có phải rằng bạn sẽ phải sửa lại toàn bộ các câu truy vấn bạn đã viết? Có thể bạn sẽ trả lời rằng "tớ control bằng data modeling". Nhưng trường hợp này chỉ đúng cho các ứng dụng đơn lẽ. Bạn thử tưởng tượng một Project cỡ lớn với nhiều application, website với một CSDL tập trung. Cụ thể vài ví dụ về Project mà mình cho là cỡ lớn này nhé:
+ Hệ thống quản lý ngành y tế của một tỉnh, quản lý từ cấp sở đến các phòng đến các cơ sở y tế, bệnh viện. Mỗi một cấp quản lý có phần mềm quản lý riêng chuyên về công việc của mình nhưng tất cả đều sử dụng chung 1 CSDL, kể cả website của ngành y tế tỉnh đó cũng lấy dữ liệu từ CSDL này.
+ Hệ thống quản lý thuế ...
+ Một game online có nhiều ứng dụng run trên nhiều server như: Connect Server, Login Server, Authentication Server, Game Server, Web ... tất cả chúng đều dùng chung 1 CSDL
Nếu bạn thêm field hoặc bớt field hoặc chỉnh sửa Table ..., nếu không dùng Store Procedure chắc chắn bạn sẽ phải chỉnh sửa code cho từng ứng dụng, website đã viết... tốn rất nhiều chi phí và thời gian (nhiều khi hàng năm trời) cho việc sửa này... mà chưa chắc gì hệ thống đã hoạt động ổn định, lỗi mọi nơi sẽ rất khó kiểm soát.
Để hiểu đơn giản, bạn có thể coi stored programs (bao gồm: stored procedure, stored function, triggers) là các hàm thao tác trực tiếp với data, do các hệ quản trị CSDL cung cấp, ở đây là MySQL (chỉ có từ ver 5 trở đi).
Thay vì bạn phải viết code tương tác với data (thêm mới, sửa, xóa, check xem user có tồn tại hay không,....) bằng các ngôn ngữ lập trình như PHP, Java,..., bạn có thể viết 1 lần duy nhất bằng các lệnh theo cấu trúc của MySQL, và nó sẽ chạy ở bên trong MySQL. Bạn có thể gọi nó bằng PHP, Java, .NET thông qua các câu lệnh gọi Stored.
Việc sử dụng Stored có mấy lợi điểm:
1. Đảm bảo security hơn cho database, các hàm tương tác có thể sẽ do DBA viết, và các bạn chỉ cần gọi, không nhất thiết phải can thiệp trực tiếp vào database.
2. Cấu trúc hóa tốt hơn, nếu db có thay đổi (thêm trường,...) thì chủ yếu sẽ sửa ở Stored, còn lại các code chính viết trên tầng trên (PHP, Java,...) sẽ ít phải sửa hơn.
3. Giảm tải về Network traffic, được sử dụng tập trung hóa, chuyên nghiệp hơn.
4. Có 1 số benchmark (không nhớ chính xác) thử nghiệm thấy tốc độ thực thi các Stored nhanh hơn các câu lệnh SQL gọi từ code (trừ Oracle). Cái này có thể đúng, vì các Stored được compile và lưu trữ trong MySQL, có cơ chế cache code, nên có thể thực thi nhanh hơn.
Yếu điểm:
Chỉ sử dụng được cho hệ CSDL đó, khi cần thay đổi DB, sẽ phải viết lại từ đầu.
SP chứa các phép toán, các câu lệnh xử lý, lệnh điều kiện.....
Qui tắc viết: CREATE PROCEDURE <ten_thu_tuc> [Khai báo các tham số đầu vào, đầu ra] AS [Phần lệnh thủ tục] GO
Một ứng dụng tốt phải đảm bảo được các yếu tố: usability, scalability, integrity, extensibility, security, và availability. Trong đó extensibility là một yếu tố tương đối quan trọng (nếu như bạn không muốn sau này phải làm lại một ứng dụng mới).
Nhiều người cho rằng Store Procedure có vai trò như database-related, một số khác lại cho rằng nó có vai trò như data architecture. Các data architect cũng gần giống như các data modeling. Tôi thì không quan tâm mấy đến những sự khác biệt này mà chỉ đưa ra cho bạn thấy một trong nhiều trường hợp cụ thể để giải thích tại sao lại dùng Store Procedure:
Ví dụ bạn có 1 website hoặc ứng dụng có truy vấn CSDL. Và khi code, bạn đã viết rất nhiều câu truy vấn khác nhau. Giả sử sau này muốn thêm một field dữ liệu mới vào một table nào đó thì có phải rằng bạn sẽ phải sửa lại toàn bộ các câu truy vấn bạn đã viết? Có thể bạn sẽ trả lời rằng "tớ control bằng data modeling". Nhưng trường hợp này chỉ đúng cho các ứng dụng đơn lẽ. Bạn thử tưởng tượng một Project cỡ lớn với nhiều application, website với một CSDL tập trung. Cụ thể vài ví dụ về Project mà mình cho là cỡ lớn này nhé:
+ Hệ thống quản lý ngành y tế của một tỉnh, quản lý từ cấp sở đến các phòng đến các cơ sở y tế, bệnh viện. Mỗi một cấp quản lý có phần mềm quản lý riêng chuyên về công việc của mình nhưng tất cả đều sử dụng chung 1 CSDL, kể cả website của ngành y tế tỉnh đó cũng lấy dữ liệu từ CSDL này.
+ Hệ thống quản lý thuế ...
+ Một game online có nhiều ứng dụng run trên nhiều server như: Connect Server, Login Server, Authentication Server, Game Server, Web ... tất cả chúng đều dùng chung 1 CSDL
Nếu bạn thêm field hoặc bớt field hoặc chỉnh sửa Table ..., nếu không dùng Store Procedure chắc chắn bạn sẽ phải chỉnh sửa code cho từng ứng dụng, website đã viết... tốn rất nhiều chi phí và thời gian (nhiều khi hàng năm trời) cho việc sửa này... mà chưa chắc gì hệ thống đã hoạt động ổn định, lỗi mọi nơi sẽ rất khó kiểm soát.
Để hiểu đơn giản, bạn có thể coi stored programs (bao gồm: stored procedure, stored function, triggers) là các hàm thao tác trực tiếp với data, do các hệ quản trị CSDL cung cấp, ở đây là MySQL (chỉ có từ ver 5 trở đi).
Thay vì bạn phải viết code tương tác với data (thêm mới, sửa, xóa, check xem user có tồn tại hay không,....) bằng các ngôn ngữ lập trình như PHP, Java,..., bạn có thể viết 1 lần duy nhất bằng các lệnh theo cấu trúc của MySQL, và nó sẽ chạy ở bên trong MySQL. Bạn có thể gọi nó bằng PHP, Java, .NET thông qua các câu lệnh gọi Stored.
Việc sử dụng Stored có mấy lợi điểm:
1. Đảm bảo security hơn cho database, các hàm tương tác có thể sẽ do DBA viết, và các bạn chỉ cần gọi, không nhất thiết phải can thiệp trực tiếp vào database.
2. Cấu trúc hóa tốt hơn, nếu db có thay đổi (thêm trường,...) thì chủ yếu sẽ sửa ở Stored, còn lại các code chính viết trên tầng trên (PHP, Java,...) sẽ ít phải sửa hơn.
3. Giảm tải về Network traffic, được sử dụng tập trung hóa, chuyên nghiệp hơn.
4. Có 1 số benchmark (không nhớ chính xác) thử nghiệm thấy tốc độ thực thi các Stored nhanh hơn các câu lệnh SQL gọi từ code (trừ Oracle). Cái này có thể đúng, vì các Stored được compile và lưu trữ trong MySQL, có cơ chế cache code, nên có thể thực thi nhanh hơn.
Yếu điểm:
Chỉ sử dụng được cho hệ CSDL đó, khi cần thay đổi DB, sẽ phải viết lại từ đầu.