Tôi biết rằng chúng tôi có xu hướng tránh các con trỏ và vòng lặp trong SQL Server bằng mọi giá, nhưng một số tình huống mà bạn thực sự cần các truy vấn thủ tục và các truy vấn dựa trên tập hợp sẽ không cung cấp cho bạn kết quả là gì?
Tôi hiểu sự khác biệt giữa hai người, tôi chưa bao giờ gặp phải tình huống cần sử dụng con trỏ. Tôi tự hỏi nếu có những tình huống như vậy.
Câu trả lời:
Theo kinh nghiệm của tôi, tôi đã gặp phải một vài lần khi các phương pháp tiếp cận thủ tục / lặp đi lặp lại được bảo hành.
Nếu tôi muốn thay đổi kiểu dữ liệu từ số thực sang số thập phân trong một bảng có 500 cột được gõ sai như câu hỏi SO này , thì một con trỏ là một cách tiếp cận tốt vì DDL không cho phép thay đổi nhiều cột trong một câu lệnh.
Nếu bạn có cuốn sách SQL Server Deep Dives của SQL Server , chương 4 "Lặp lại dựa trên tập hợp: phương án thứ ba" của Hugo Kornelis có một số trường hợp sử dụng tuyệt vời cho các hoạt động dựa trên con trỏ / bộ kết hợp. Hai trong số các vấn đề kinh điển mà tác giả chương tham khảo là Chạy Tổng cộng và Đóng gói Thùng .
Tôi đã sử dụng phương pháp lặp dựa trên tập hợp với thành công tốt cho một quy trình được thiết kế kém mà tôi được thừa hưởng ở công việc cuối cùng. Nói tóm lại, có một quá trình mỗi năm một lần phải cập nhật 50-75M hàng và cố gắng thực hiện trong một bộ duy nhất sẽ thổi bay nhật ký của chúng tôi. Bằng cách phân chia các bản cập nhật thành các lô N hàng nhỏ hơn, nó cho phép nhật ký theo kịp và thực sự kết thúc nhanh hơn năm trước khi chúng chỉ phân bổ thêm một tấn không gian đĩa.
Khi một cái gì đó không thể được thực hiện dựa trên.
Tất nhiên là chảy máu. Nhưng lưu ý rằng có sự khác biệt trong "không đặt dựa trên" và dân gian sử dụng giải pháp thủ tục vì họ không hiểu các bộ hoặc không biết cách thực hiện với mã dựa trên tập hợp.
Một ví dụ về mã thủ tục sẽ gửi email mỗi hàng có nội dung khác nhau trên mỗi hàng
Rất nhiều mã SQL để sử dụng DBA là thủ tục. Ví dụ: lặp (CURSOR hoặc WHILE: không có sự khác biệt) trên cơ sở dữ liệu và bảng để xây dựng lại các chỉ mục và cập nhật số liệu thống kê.
Một số cấu trúc SQL cho phép xử lý từng hàng trong ngữ cảnh của một tập hợp, chẳng hạn như CROSS ỨNG DỤNG như thế này trên SO: CHỌN 5 hàng hàng đầu cho mỗi FK (cũng lưu ý giải pháp ROW_NUMBER ())
Chỉnh sửa: mở rộng câu trả lời của @ billinkc ...
CROSS ỨNG DỤNG cho phép thiết lập các hoạt động dựa trên UDF có "API hàng đơn"
Tôi biết bạn đang hỏi về SQL Server, nhưng trong thế giới Oracle (trước đây), các bảng tạm thời có chi phí rất cao, vì vậy các quy trình và trình kích hoạt dựa trên con trỏ nhanh hơn và "chi phí" cho máy chủ. Trong SQL Server, các con trỏ được sử dụng có chi phí cao hơn nhiều so với các bảng tạm thời, do đó việc viết mã dựa trên con trỏ không được khuyến khích. Tôi khá chắc chắn rằng những khác biệt này đã được loại bỏ trong thập kỷ qua.
Để đối phó với những tình huống này, hầu hết mọi người đều có một quy tắc chung để tránh đưa logic kinh doanh vào cơ sở dữ liệu. Nếu bạn hoàn toàn có thể luôn luôn làm điều đó, thì sẽ không có bất kỳ lý do nào cho logic thủ tục trong cả T-SQL và PL / SQL. Cơ sở dữ liệu quan hệ là tuyệt vời ở logic dựa trên thiết lập. Hầu hết các ngôn ngữ lập trình hiện đại là tuyệt vời ở logic thủ tục. Tốt nhất là sử dụng mỗi người cho những gì họ giỏi.
Một số kích hoạt kiểm toán mà tôi đã làm việc có các quy tắc khá phức tạp đối với những gì phải được kiểm tra và nơi mọi thứ phải được cập nhật / ghi lại. Một số là để giữ cho các hệ thống báo cáo đồng bộ với các hệ thống giao dịch (đó không phải là lựa chọn của tôi, nhưng họ muốn nó theo cách đó). Một số là cho một hệ thống công thức . Danh mục thuốc là một danh sách các loại thuốc, và đối với mỗi công ty bảo hiểm, những gì họ sẽ / sẽ không bao gồm, và nếu được kê đơn thuốc_X thì những thay thế nào được bảo hiểm chi trả. Nó cũng phổ biến cho các chính sách nhóm khác nhau tại cùng một công ty bảo hiểm để trả cho các loại thuốc khác nhau.