maestro09
Bác nói câu này làm em hơi bất ngờ vì xưa nay em luôn ghi nhớ SP có tốc độc thực thi cao hơn query bt. Bác có thể nói rõ hơn cho em biết đc ko ạ, vì em toàn tự tìm hiểu vấn đề này, thầy em chả ông nào chỉ cho 
Thêm nữa thế này bác ạ. Em vẫn biết 1 giải pháp hoàn hảo cho mọi vấn đề là điều ko tưởng. Nhưng mà bác có thể cho em ví dụ thực tiễn khi nào dùng SP và khi nào ko cần dùng ko ạ. Câu này em hỏi luôn bác Cobain nhé 
nôm na là thế này, với Stored procedure, RDBMS có khả năng nhận diện và cache cái execution plan, tức là nó biết được cần lấy dữ liệu từ cột nào, join từ bảng nào, vv và vv. vì vậy lần sau nó ko cần phải tốn thời gian để evaluate cái query nữa, cứ thế mà chạy thôi.
nếu bạn chạy dynamic query, kiểu string sql = "select * from abc where columnA = " + temp; chẳng hạn, thì RDBMS nó không có khả năng lưu cái execution plan đấy, nên mỗi lần chạy nó lại phải evaluate lại, thành ra ảnh hưởng đến tốc độ.
cái mà người ta khuyên dùng là parameterized query. kiểu dư lày:
SqlConnection sqlCon = new SqlConnection("select * from abc where columnA = @columnA";
sqlCon.Parameters.Add("@columnA", temp, DbType.String");
...
(mình viết pseudo code thôi, hy vọng bạn hiểu được ý tưởng)
lúc này thì RDBMS cũng có khả năng lưu và sử dụng lại execution plan.
người ta khuyên dùng SP vì một số lý do như sau:
- 1 là hạn chế SQL injection. vì về cơ bản SP đã được parameterized, tránh được tình trạng concentrate string để build query. tất nhiên cái này chỉ là pattern để giảm, còn trong sp bạ hoàn toàn có thể concentrate string để build dynamic query.
- 2 là tập trung các logic xử lý DB vào DB, không để phân tán, đồng thời tách nó ra khỏi business layer. cái này đôi khi gây tranh cãi vì một số người prefer coi những logic xử lý này là một phần của business layer, chứ ko thuộc vào data acess layer nữa. tất nhiên là tùy theo cách tiếp cận người ta có thể chọn SP hay parameterized query
