Tôi đang làm việc tại một dự án ở một trong 3 công ty tư vấn CNTT hàng đầu thế giới và được một DBA nói rằng các quy trình lưu trữ nhà nước tốt nhất của công ty không phải là "thực tiễn tốt nhất". Điều này trái ngược với mọi thứ tôi đã học.

Các thủ tục được lưu trữ cung cấp cho bạn việc tái sử dụng mã và đóng gói (hai trụ cột của phát triển phần mềm), bảo mật (bạn có thể cấp / thu hồi quyền trên một Proc được lưu trữ riêng lẻ), bảo vệ bạn khỏi các cuộc tấn công SQL và cũng giúp tăng tốc (mặc dù DBA nói rằng bắt đầu với SQL Server 2008, ngay cả các truy vấn SQL thông thường cũng được biên dịch nếu chúng chạy đủ số lần).

Chúng tôi đang phát triển một ứng dụng phức tạp bằng phương pháp phát triển phần mềm Agile. Bất cứ ai cũng có thể nghĩ ra những lý do chính đáng tại sao họ không muốn sử dụng các procs được lưu trữ? Tôi đoán là các DBA không muốn duy trì các procs được lưu trữ đó, nhưng dường như có quá nhiều tiêu cực để biện minh cho một quyết định thiết kế như vậy.

Theo kinh nghiệm của tôi khi làm việc trong các dự án rất lớn, bạn phải rất rõ ràng về nơi logic kinh doanh sống. Nếu bạn cho phép một môi trường nơi các nhà phát triển riêng lẻ có thể đưa logic nghiệp vụ vào lớp đối tượng kinh doanh hoặc trong một quy trình được lưu trữ khi họ thấy phù hợp, một ứng dụng lớn trở nên RẤT khó hiểu và duy trì.

Các thủ tục được lưu trữ là rất tốt để tăng tốc các hoạt động DB nhất định. Quyết định kiến ​​trúc của tôi là để lại tất cả logic trong lớp nghiệp vụ của ứng dụng và sử dụng các thủ tục được lưu trữ theo cách nhắm mục tiêu để cải thiện hiệu suất trong đó điểm chuẩn cho thấy nó được bảo hành.

Một số quan sát

Các thủ tục lưu trữ cung cấp cho bạn tái sử dụng mã và đóng gói (hai trụ cột của phát triển phần mềm),

Chỉ khi bạn sử dụng chúng một cách chính xác trong bối cảnh mà chúng được sử dụng. Yêu cầu tương tự có thể được nói về các hàm (trong lập trình có cấu trúc) hoặc các phương thức (trong lập trình hướng đối tượng), tuy nhiên, chúng ta thấy các hàm 1K và các đối tượng mega-ass.

Cổ vật không cung cấp cho bạn những lợi ích. Việc sử dụng hợp lý những đồ tạo tác đó là những gì mang lại những lợi ích đó.

bảo mật (bạn có thể cấp / thu hồi quyền trên một Proc được lưu trữ riêng lẻ),

Đúng. Đây là một điểm tốt và một trong những lý do chính tôi thích các thủ tục được lưu trữ. Chúng cung cấp một điều khiển truy cập chi tiết hơn so với những gì có thể đạt được thông thường chỉ bằng các lượt xem và tài khoản người dùng.

bảo vệ bạn khỏi các cuộc tấn công SQL,

Điều đó không cụ thể đối với SP vì bạn có thể đạt được mức bảo vệ tương tự với các câu lệnh SQL được tham số hóa và quá trình lọc đầu vào. Tôi sẽ sử dụng SP ngoài những SP đó, tuy nhiên, là vấn đề "bảo mật chuyên sâu" .

và cũng giúp tốc độ (mặc dù DBA nói rằng bắt đầu với SQL Server 2008, ngay cả các truy vấn SQL thông thường cũng được biên dịch nếu chúng chạy đủ thời gian).

Đây là cơ sở dữ liệu cụ thể của nhà cung cấp, nhưng nói chung DBA của bạn là đúng. Các câu lệnh SQL (tĩnh hoặc tham số hóa) được biên dịch. SP giúp đỡ nếu bạn muốn / cần tổng hợp và tính toán dữ liệu mà bạn không thể làm với các câu lệnh SQL đơn giản, nhưng được tích hợp chặt chẽ với SQL và không đảm bảo chuyến đi khứ hồi đến máy chủ ứng dụng.

Một ví dụ điển hình là truy vấn dữ liệu vào một con trỏ tạm thời (hoặc con trỏ) để chạy SQL khác. Bạn có thể thực hiện lập trình trong máy chủ ứng dụng hoặc bạn có thể lưu nhiều chuyến đi khứ hồi bằng cách thực hiện trong db.

Điều này không phải là tiêu chuẩn, tuy nhiên. Nếu bạn có nhiều trường hợp như vậy, thì đó là dấu hiệu của thiết kế cơ sở dữ liệu xấu (hoặc bạn đang lấy dữ liệu từ các lược đồ cơ sở dữ liệu không tương thích giữa các phòng ban.)

Chúng tôi đang phát triển một ứng dụng phức tạp bằng phương pháp phát triển phần mềm Agile.

Agility phải làm với các quy trình kỹ thuật phần mềm và quản lý yêu cầu, chứ không phải công nghệ.

Bất cứ ai cũng có thể nghĩ ra những lý do chính đáng tại sao họ không muốn sử dụng các procs được lưu trữ?

Câu hỏi sai

Câu hỏi sai và tương đương với câu hỏi "có lý do chính đáng nào để không sử dụng GOTO" không? Tôi bên cạnh Niklaus Wirth nhiều hơn với Dijkstra về chủ đề này. Tôi có thể hiểu tình cảm của Dijkstra đến từ đâu, nhưng tôi không tin rằng nó có thể áp dụng 100% trong mọi trường hợp. Tương tự với procs cửa hàng và bất kỳ công nghệ.

Một công cụ tốt khi được sử dụng tốt cho mục đích của nó và khi đó là công cụ tốt nhất cho nhiệm vụ cụ thể. Sử dụng nó không phải là một dấu hiệu cho thấy công cụ này sai, nhưng người sử dụng không biết mình đang làm gì.

Câu hỏi thích hợp là "loại mô hình sử dụng thủ tục được lưu trữ nào nên tránh." Hoặc, "trong những điều kiện tôi nên (hoặc không nên) sử dụng các thủ tục được lưu trữ" . Tìm kiếm lý do không sử dụng công nghệ chỉ đơn giản là đổ lỗi cho công cụ thay vì đặt trách nhiệm kỹ thuật thẳng vào nơi nó thuộc về - trong kỹ sư.

Nói cách khác, đó là một cảnh sát hoặc tuyên bố thiếu hiểu biết.

Tôi đoán là các DBA không muốn duy trì các procs được lưu trữ đó, nhưng dường như có quá nhiều tiêu cực để biện minh cho một quyết định thiết kế như vậy.

Những gì họ đang làm sau đó là dự đoán kết quả của các quyết định kỹ thuật tồi của họ trên các công cụ mà họ sử dụng kém.

Làm gì trong trường hợp của bạn?

Kinh nghiệm của tôi là, khi ở Rome, hãy làm như người La Mã làm .

Đừng chống lại nó. Nếu những người trong công ty của bạn muốn dán nhãn procs cửa hàng là một thực hành xấu, hãy để họ. Tuy nhiên, hãy lưu ý rằng đây có thể là một lá cờ đỏ trong thực hành kỹ thuật của họ.

Ghi nhãn điển hình của những thứ như thông lệ xấu thường được thực hiện trong các tổ chức có hàng tấn lập trình viên bất tài. Bằng cách liệt kê một số thứ nhất định, tổ chức cố gắng hạn chế thiệt hại gây ra trong nội bộ bằng sự bất tài của chính họ. Tôi không shit bạn.

Tổng quát là mẹ của tất cả các vít lên. Nói rằng procs lưu trữ (hoặc bất kỳ loại công nghệ) là một thực tiễn xấu, đó là một khái quát. Khái quát là cop-outs cho người bất tài. Các kỹ sư không làm việc với sự khái quát trắng trợn. Họ phân tích trên cơ sở từng trường hợp cụ thể, phân tích đánh đổi và thực hiện các quyết định và giải pháp kỹ thuật theo các sự kiện có sẵn, trong bối cảnh họ phải giải quyết một vấn đề.

Các kỹ sư giỏi không gắn nhãn những thứ là thông lệ xấu theo những cách khái quát như vậy. Họ nhìn vào vấn đề, chọn công cụ phù hợp, đánh đổi. Nói cách khác, họ làm kỹ thuật.

Ý kiến ​​của tôi về cách không sử dụng chúng

• Đừng đặt logic phức tạp ngoài việc thu thập dữ liệu (và có lẽ một số biến đổi) trong chúng. Bạn có thể đặt một số logic tạo khối dữ liệu vào chúng hoặc tổng hợp kết quả của nhiều truy vấn với chúng. Nhưng đó là về nó. Bất cứ điều gì ngoài đó sẽ đủ điều kiện là logic kinh doanh sẽ nằm ở một nơi khác.

• Đừng sử dụng chúng làm cơ chế bảo vệ chống lại việc tiêm SQL. Bạn để chúng ở đó trong trường hợp có điều gì đó không tốt với chúng , nhưng cần có một loạt logic phòng thủ trước mặt chúng - xác thực / chà sát phía máy khách, xác thực / chà sát phía máy chủ, có thể chuyển đổi thành các loại có ý nghĩa trong bạn mô hình miền và cuối cùng được chuyển đến các câu lệnh tham số hóa (có thể là các câu lệnh SQL được tham số hóa hoặc các procs được lưu trữ tham số.)

• Đừng biến cơ sở dữ liệu thành nơi duy nhất chứa procs cửa hàng của bạn. Các procs cửa hàng của bạn nên được xử lý giống như bạn đối xử với mã nguồn C # hoặc Java của mình. Đó là, kiểm soát nguồn định nghĩa văn bản của procs cửa hàng của bạn. Mọi người cho rằng cửa hàng procs không thể được kiểm soát nguồn - bullcrap, họ chỉ không biết họ đang nói về cái quái gì.

Ý kiến ​​của tôi về cách sử dụng chúng

• Ứng dụng của bạn yêu cầu dữ liệu cần được chuyển đổi hoặc tổng hợp từ nhiều truy vấn hoặc chế độ xem. Bạn có thể giảm tải từ ứng dụng vào db. Ở đây bạn phải thực hiện phân tích hiệu suất vì a) các công cụ cơ sở dữ liệu hiệu quả hơn mà các máy chủ ứng dụng thực hiện những việc này, nhưng b) máy chủ ứng dụng (đôi khi) dễ dàng mở rộng theo chiều ngang.

• Kiểm soát truy cập hạt mịn. Bạn không muốn một số kẻ ngốc chạy cartesian tham gia vào db của bạn, nhưng bạn không thể cấm mọi người thực thi các câu lệnh SQL tùy ý như thế. Một giải pháp điển hình là cho phép các câu lệnh SQL tùy ý trong các môi trường phát triển và UAT, trong khi cấm chúng trong các môi trường sản xuất và hệ thống. Bất kỳ tuyên bố nào phải đưa nó vào hệ thống hoặc sản xuất đều đi vào một quy trình lưu trữ, được xem xét mã bởi cả nhà phát triển và dbas.

Bất kỳ nhu cầu hợp lệ nào để chạy câu lệnh SQL không có trong kho lưu trữ đều phải thông qua một tên người dùng / tài khoản và nhóm kết nối khác nhau (với việc sử dụng được giám sát và khuyến khích cao.)

• Trong các hệ thống như Oracle, bạn có thể có quyền truy cập vào LDAP hoặc tạo liên kết tượng trưng cho cơ sở dữ liệu bên ngoài (giả sử gọi một cửa hàng Proc trên db của đối tác kinh doanh thông qua vpn.) Cách dễ dàng để làm mã spaghetti, nhưng đôi khi đúng với mọi mô hình lập trình bạn có các yêu cầu kinh doanh / môi trường cụ thể mà đây là giải pháp duy nhất. Cửa hàng procs giúp gói gọn sự khó chịu đó ở một nơi, gần với dữ liệu và không phải truy cập vào máy chủ ứng dụng.

Việc bạn chạy cái này trên db như là một cửa hàng Proc hay trên máy chủ ứng dụng của bạn tùy thuộc vào phân tích đánh đổi mà bạn, với tư cách là một kỹ sư, phải thực hiện. Cả hai tùy chọn phải được phân tích và chứng minh bằng một số loại phân tích. Đi bằng cách này hay cách khác bằng cách đơn giản cáo buộc phương án khác là "thực hành tồi", đó chỉ là một sự đồng ý kỹ thuật khập khiễng.

• Trong các trường hợp đơn giản là bạn không thể mở rộng quy mô máy chủ ứng dụng của mình (.ie. Không có ngân sách cho các trường hợp phần cứng hoặc đám mây mới) nhưng với nhiều khả năng trên back-end db (điều này điển hình hơn mà nhiều người quan tâm thừa nhận), nó trả tiền để di chuyển logic kinh doanh để lưu trữ procs. Không đẹp và có thể dẫn đến các mô hình miền thiếu máu ... nhưng sau đó một lần nữa ... phân tích đánh đổi, điều mà hầu hết các phần mềm hack đều hấp dẫn.

Cho dù điều đó có trở thành một giải pháp lâu dài hay không, điều đó cụ thể đối với các ràng buộc được quan sát tại thời điểm cụ thể đó.

Hy vọng nó giúp.

Lý do là việc dựa vào lớp thủ tục được lưu trữ sẽ hạn chế tính di động và ràng buộc bạn với một DB nhất định. Thêm chi phí bảo trì cũng được trích dẫn là một lý do. Tôi cũng muốn bình luận về điểm này bạn đã thực hiện:

(thủ tục lưu trữ) bảo vệ bạn khỏi các cuộc tấn công SQL SQL

Đó thực sự là truy vấn tham số bảo vệ bạn, điều mà bạn có thể dễ dàng thực hiện trong truy vấn sql văn bản thuần túy.

Một số lý do mà tôi đồng ý các procs được lưu trữ không phải là cách thực hành tốt nhất.

• Logic nghiệp vụ và ứng dụng phải nằm trong mã không có trong cơ sở dữ liệu. Đặt logic trong DB là trộn lẫn mối quan tâm.
• Bạn không thể kiểm tra các procs được lưu trữ liền mạch như mã trong các dự án kiểm tra đơn vị thông thường của bạn với phần còn lại của logic ứng dụng.
• Tôi không thấy các procs được lưu trữ có lợi cho việc kiểm tra chương trình đầu tiên khi tôi viết mã.
• Các procs được lưu trữ không dễ gỡ lỗi như mã ứng dụng khi bạn gỡ lỗi chương trình trong IDE của mình.
• Kiểm soát phiên bản / Kiểm soát nguồn của SP so với mã thông thường

Các thủ tục lưu trữ cung cấp cho bạn tái sử dụng mã và đóng gói (hai trụ cột của phát triển phần mềm),

Có, nhưng với chi phí có thể đáp ứng các mục tiêu thiết kế nhanh nhẹn khác. Chúng khó khăn hơn để duy trì, vì một điều. Nếu dự án tôi đang thực hiện là bất kỳ dấu hiệu nào, có thể bạn sẽ kết thúc với nhiều SP không tương thích, thực hiện cùng một công việc, không có lợi ích.

bảo vệ bạn khỏi các cuộc tấn công SQL,

Không họ không. Tôi thậm chí không thể đoán được ý tưởng này có thể đến từ đâu, vì tôi nghe nó nói thường xuyên, và nó đơn giản là không đúng. Nó có thể giảm thiểu một số loại tấn công SQL SQL nhất định, nhưng nếu bạn không sử dụng truy vấn được tham số hóa ngay từ đầu, điều đó sẽ không thành vấn đề. Tôi vẫn có thể '; Tài khoản DROP TABLE; -

và cũng giúp tốc độ (mặc dù DBA nói rằng bắt đầu với SQL Server 2008, ngay cả các truy vấn SQL thông thường cũng được biên dịch nếu chúng chạy đủ thời gian).

Chúng cũng thường được biên dịch khi bạn sử dụng các câu lệnh được chuẩn bị, tham số hóa (ít nhất là với một số DB tôi đã sử dụng). Vào thời điểm ứng dụng của bạn bắt đầu thực hiện truy vấn (hoặc đặc biệt là khi bạn thực hiện cùng một truy vấn đã chuẩn bị nhiều lần), bất kỳ lợi thế về hiệu suất nào mà bạn nghĩ rằng SP của bạn có hoàn toàn không cần thiết.

Các chỉ lý do để sử dụng một thủ tục lưu trữ, IMHO, là khi bạn phải làm một phức tạp, truy vấn đa dàn dựng mà kéo từ nhiều đối chiếu nguồn. SP không nên chứa logic quyết định cấp thấp và chúng không bao giờ nên đơn giản gói gọn một truy vấn đơn giản khác. Không có lợi ích và chỉ có nhiều nhược điểm.

Nghe DBA của bạn. Anh ấy biết những gì lên.

Đây là dòng chính thức khi tôi làm việc cho một trong Năm Lớn một vài năm trước. Lý do là vì các SP được gắn với các triển khai cụ thể (PL / SQL so với T / SQL so với ...), nên chúng hạn chế các lựa chọn công nghệ một cách không cần thiết.

Đã sống qua việc di chuyển một hệ thống lớn từ T / SQL sang PL / SQL, tôi có thể hiểu được đối số. Tôi nghĩ rằng đó là một chút của canard - có bao nhiêu nơi thực sự di chuyển từ cơ sở dữ liệu này sang cơ sở dữ liệu khác?

Tất cả ba công ty tôi làm việc cho các thủ tục được lưu trữ đã sử dụng cho logic ứng dụng của họ với SQL Server. Tôi đã không thực sự nhìn mọi thứ theo cách khác. Nhưng với tôi họ là một mớ hỗn độn lớn. Thông thường không có cơ sở xử lý lỗi rất tốt hoặc cơ sở sử dụng lại mã với các thủ tục được lưu trữ.

Giả sử bạn có một thủ tục được lưu trữ trả về một tập dữ liệu bạn muốn sử dụng, làm thế nào bạn có thể sử dụng nó trong các thủ tục được lưu trữ trong tương lai? Các cơ chế trên SQL Server không được tốt lắm. EXEC INTO ... chỉ hoạt động ở một hoặc hai cấp) lồng nhau (tôi quên ngay bây giờ). Hoặc bạn phải xác định trước một bảng làm việc và xử lý nó. Hoặc bạn cần tạo trước một bảng tạm thời và có quy trình điền vào bảng. Nhưng điều gì sẽ xảy ra nếu hai người gọi một bảng tạm thời là cùng một thứ trong hai thủ tục khác nhau mà họ không bao giờ có kế hoạch sử dụng cùng một lúc? Trong bất kỳ ngôn ngữ lập trình thông thường nào, bạn chỉ có thể trả về một mảng từ một hàm hoặc trỏ đến một cấu trúc đối tượng / toàn cầu được chia sẻ giữa chúng (ngoại trừ các ngôn ngữ chức năng nơi bạn trả về cấu trúc dữ liệu thay vì chỉ thay đổi cấu trúc toàn cầu ... )

Làm thế nào về việc sử dụng lại mã? Nếu bạn bắt đầu đưa các biểu thức phổ biến vào UDF (hoặc thậm chí tệ hơn các truy vấn phụ), bạn sẽ làm chậm mã dừng lại. Bạn không thể gọi một thủ tục được lưu trữ để thực hiện tính toán cho một cột (trừ khi bạn sử dụng một con trỏ, chuyển từng giá trị cột từng cái một, sau đó cập nhật bảng / tập dữ liệu của bạn bằng cách nào đó). Vì vậy, về cơ bản để có được hiệu suất cao nhất, bạn cần phải cắt / dán các biểu thức phổ biến khắp nơi là một cơn ác mộng bảo trì ... Với ngôn ngữ lập trình, bạn có thể tạo một hàm để tạo SQL chung và sau đó gọi nó từ mọi nơi khi xây dựng chuỗi SQL. Sau đó, nếu bạn cần điều chỉnh công thức, bạn có thể thực hiện thay đổi ở một nơi duy nhất ...

Làm thế nào về xử lý lỗi? SQL Server có nhiều lỗi ngay lập tức ngăn chặn thủ tục được lưu trữ thực thi và một số lỗi thậm chí buộc phải ngắt kết nối. Từ năm 2005 có thử / bắt nhưng vẫn còn một số lỗi không thể bắt được. Ngoài ra, điều tương tự cũng xảy ra với sao chép mã trên mã xử lý lỗi và bạn thực sự không thể vượt qua các trường hợp ngoại lệ một cách dễ dàng hoặc đưa chúng lên mức cao hơn dễ dàng như hầu hết các ngôn ngữ lập trình .....

Cũng chỉ là tốc độ. Rất nhiều hoạt động trên bộ dữ liệu không được định hướng SET. Nếu bạn cố gắng thực hiện các công cụ định hướng theo hàng, bạn sẽ sử dụng một con trỏ hoặc bạn sẽ sử dụng một "con trỏ" (khi các nhà phát triển thường truy vấn từng hàng một và lưu trữ nội dung vào các biến @ giống như một con trỏ. .. Mặc dù điều này thường chậm hơn con trỏ FORWARD_ONLY). Với SQL Server 2000, tôi đã có một cái gì đó chạy trong 1 giờ trước khi tôi giết nó. Tôi viết lại mã đó trong Perl và nó đã hoàn thành sau 20 phút. Khi một ngôn ngữ kịch bản chậm hơn 20-80 lần so với C hút SQL trong hiệu suất, bạn chắc chắn không có hoạt động định hướng hàng viết kinh doanh trong SQL.

Bây giờ SQL Server đã tích hợp CLR và rất nhiều vấn đề này sẽ biến mất nếu bạn sử dụng thủ tục lưu sẵn CLR. Nhưng nhiều DBA không biết cách viết chương trình .NET hoặc tắt CLR do lo ngại bảo mật và gắn bó với Transact SQL .... Ngoài ra, ngay cả với CLR, bạn vẫn gặp vấn đề chia sẻ dữ liệu giữa nhiều quy trình một cách hiệu quả .

Ngoài ra, nói chung, điều khó nhất để mở rộng quy mô là cơ sở dữ liệu. Nếu tất cả logic kinh doanh của bạn nằm trong cơ sở dữ liệu, thì khi cơ sở dữ liệu trở nên quá chậm, bạn sẽ gặp vấn đề. Nếu bạn có một lớp nghiệp vụ, bạn có thể chỉ cần thêm bộ nhớ đệm và nhiều máy chủ doanh nghiệp hơn để tăng hiệu suất. Theo truyền thống, một máy chủ khác để cài đặt windows / linux và chạy .NET / Java rẻ hơn nhiều so với việc mua một máy chủ cơ sở dữ liệu khác và cấp phép cho nhiều SQL Server hơn. SQL Server hiện có nhiều hỗ trợ phân cụm hơn, ban đầu nó không thực sự có. Vì vậy, nếu bạn có nhiều tiền, bạn có thể thêm phân cụm hoặc thậm chí thực hiện một số vận chuyển nhật ký để tạo nhiều bản sao chỉ đọc. Nhưng nhìn chung, việc này sẽ tốn kém hơn nhiều so với việc chỉ ghi vào bộ nhớ cache hoặc thứ gì đó.

Cũng xem các cơ sở Transact-SQL. Thao tác chuỗi? Tôi sẽ lấy các lớp Java String Class / Tokenizer / Scanner / Regex mỗi ngày. Bảng băm / Danh sách liên kết / Vv. Tôi sẽ sử dụng các khung công tác Bộ sưu tập Java, v.v ... Và tương tự cho .NET ... Cả C # và Java đều là những ngôn ngữ phát triển hơn so với Transact SQL ... Mã hóa bằng Transact-SQL khiến tôi ghen tị với C .. .

Trên các thủ tục lưu trữ cộng có hiệu quả hơn để làm việc với một tập dữ liệu lớn và áp dụng nhiều truy vấn / tiêu chí để thu nhỏ nó trước khi đưa nó trở lại lớp nghiệp vụ. Nếu bạn phải gửi một loạt các bộ dữ liệu khổng lồ đến ứng dụng khách và chia nhỏ dữ liệu tại máy khách thì sẽ không hiệu quả hơn nhiều so với việc chỉ thực hiện tất cả công việc tại máy chủ.

Thủ tục lưu trữ cũng tốt cho an ninh. Bạn có thể cắt tất cả quyền truy cập vào các bảng bên dưới và chỉ cho phép truy cập thông qua các thủ tục được lưu trữ. Với một số kỹ thuật hiện đại như XML, bạn có thể có các quy trình được lưu trữ để cập nhật hàng loạt. Sau đó, tất cả quyền truy cập được kiểm soát thông qua các thủ tục được lưu trữ miễn là chúng an toàn / chính xác, dữ liệu có thể có tính toàn vẹn hơn.

Đối số tiêm SQL không thực sự áp dụng nhiều nữa vì chúng ta có các truy vấn được tham số hóa ở phía ngôn ngữ lập trình. Ngoài ra thực sự ngay cả trước khi các truy vấn được tham số hóa thay thế một chút ("'", "' '") cũng hoạt động hầu hết thời gian (mặc dù vẫn có các thủ thuật sử dụng để đi qua cuối chuỗi để có được những gì bạn muốn).

Nhìn chung, tôi nghĩ rằng SQL và Transact SQL là những ngôn ngữ tuyệt vời để truy vấn / cập nhật dữ liệu. Nhưng để mã hóa bất kỳ loại logic nào, thực hiện thao tác chuỗi (hoặc thao tác tệp heck .... bạn sẽ ngạc nhiên về những gì bạn có thể làm với xp_cmdshell ....) xin vui lòng không. Tôi hy vọng sẽ tìm thấy một nơi trong tương lai không sử dụng các thủ tục được lưu trữ. Từ quan điểm duy trì mã, họ là một cơn ác mộng. Ngoài ra, điều gì sẽ xảy ra nếu bạn muốn chuyển đổi nền tảng (mặc dù thực sự nếu bạn đã trả tiền cho Oracle / DB2 / Sybase / Sql Server / v.v. Bạn cũng có thể lấy mọi thứ bạn có thể ra khỏi chúng bằng cách sử dụng mọi tiện ích mở rộng độc quyền mà bạn có thể giúp bạn. ..).

Cũng đáng ngạc nhiên thường logic kinh doanh không giống nhau. Trong thế giới lý tưởng, bạn sẽ đặt tất cả logic vào các thủ tục được lưu trữ và chia sẻ điều đó giữa các ứng dụng. Nhưng khá thường xuyên logic khác nhau dựa trên các ứng dụng và các thủ tục được lưu trữ của bạn cuối cùng trở thành những khối nguyên khối quá phức tạp mà mọi người sợ thay đổi và không hiểu tất cả ý nghĩa của nó. Trong khi với một ngôn ngữ hướng đối tượng tốt, bạn có thể mã hóa một lớp truy cập dữ liệu có một số giao diện / móc tiêu chuẩn mà mỗi ứng dụng có thể ghi đè lên nhu cầu của riêng họ.

Làm thế nào để bạn phiên bản thủ tục lưu trữ trên máy chủ?

Nếu bạn triển khai lại các thủ tục được lưu trữ cho máy chủ từ kiểm soát phiên bản, bạn sẽ thổi bay kế hoạch thực hiện được lưu trữ.

Các thủ tục được lưu trữ không nên được sửa đổi trực tiếp trên máy chủ, nếu không làm thế nào để bạn biết những gì thực sự đang chạy _ ngay bây giờ? Nếu không, công cụ triển khai cần truy cập để ghi các thủ tục được lưu trữ vào cơ sở dữ liệu. Bạn sẽ phải triển khai trên mọi bản dựng (kế hoạch thực hiện có thể cần phải khác)

Mặc dù các thủ tục được lưu trữ là không khả chuyển, nhưng SQL cũng không nói chung (từng thấy xử lý ngày tiên tri - uggghhh).

Vì vậy, nếu bạn muốn tính di động, hãy xây dựng API truy cập dữ liệu nội bộ. Bạn có thể gọi đây giống như các cuộc gọi chức năng, và bên trong bạn có thể xây dựng trong bất kỳ biệt ngữ nào bạn muốn, với các truy vấn được tham số hóa và nó có thể được kiểm soát theo phiên bản.

Điều này trái ngược với mọi thứ tôi đã học.

Bạn có thể cần phải ra ngoài nhiều hơn. [cười] Nghiêm túc, các procs được lưu trữ đã suy giảm ít nhất 10 năm. Khá nhiều kể từ khi n-tier thay thế máy khách-máy chủ. Sự suy giảm chỉ được tăng tốc khi áp dụng các ngôn ngữ OO như Java, C #, Python, v.v.

Điều đó không có nghĩa là các procs được lưu trữ vẫn không có những người ủng hộ và ủng hộ họ - nhưng đây là một cuộc thảo luận và tranh luận kéo dài. Nó không phải là mới, và có khả năng vẫn sẽ diễn ra trong một thời gian khá dài; IMO, đối thủ của các procs được lưu trữ rõ ràng là chiến thắng.

Các thủ tục lưu trữ cung cấp cho bạn tái sử dụng mã và đóng gói (hai trụ cột của phát triển phần mềm)

Rất đúng. Nhưng, một lớp OO được kiến ​​trúc cũng vậy.

bảo mật (bạn có thể cấp / thu hồi quyền trên một Proc được lưu trữ riêng lẻ)

Trong khi bạn có thể làm điều đó, ít người làm điều đó vì những hạn chế nghiêm trọng. Bảo mật ở cấp DB không đủ chi tiết để đưa ra quyết định nhận biết ngữ cảnh. Do hiệu suất và chi phí quản lý, nên việc kết nối theo người dùng cũng không bình thường - vì vậy bạn vẫn cần một số mức ủy quyền trong mã ứng dụng của mình. Bạn có thể sử dụng thông tin đăng nhập dựa trên vai trò, nhưng bạn sẽ cần tạo chúng cho vai trò mới, duy trì vai trò bạn đang chạy, chuyển đổi kết nối để thực hiện "cấp hệ thống" như ghi nhật ký, v.v. Và cuối cùng, nếu ứng dụng của bạn được sở hữu - kết nối của bạn với DB cũng vậy.

bảo vệ bạn khỏi các cuộc tấn công SQL SQL

Không có nhiều hơn là làm các truy vấn tham số. Mà bạn cần phải làm gì.

và cũng giúp tốc độ (mặc dù DBA nói rằng bắt đầu với SQL Server 2008, ngay cả các truy vấn SQL thông thường cũng được biên dịch nếu chúng chạy đủ thời gian).

Tôi nghĩ rằng điều đó đã bắt đầu trong MSSQL 7 hoặc 2000. Đã có rất nhiều cuộc tranh luận, đo lường và thông tin sai lệch về hiệu suất được lưu trữ so với hiệu suất SQL nội tuyến - Tôi gộp tất cả theo YAGNI. Và, nếu bạn cần nó, hãy thử nghiệm.

Chúng tôi đang phát triển một ứng dụng phức tạp bằng phương pháp phát triển phần mềm Agile. Bất cứ ai cũng có thể nghĩ ra những lý do chính đáng tại sao họ không muốn sử dụng các procs được lưu trữ?

Tôi không thể nghĩ ra nhiều lý do bạn muốn . Java / C # / bất kỳ ngôn ngữ GL thứ 3 nào đều có khả năng cao hơn nhiều so với T-SQL trong việc đóng gói, tái sử dụng và khả năng xử lý, v.v. Hầu hết trong số đó là miễn phí với ORM nửa vời.

Ngoài ra, đưa ra lời khuyên để "phân phối khi cần, nhưng không nhiều hơn" - Tôi nghĩ rằng gánh nặng của bằng chứng ngày nay là ở những người ủng hộ SP. Một lý do phổ biến cho việc lưu trữ Proc nặng là T-SQL dễ hơn OO và cửa hàng có các nhà phát triển T-SQL tốt hơn OO. Hoặc, DBA dừng ở lớp cơ sở dữ liệu và các procs được lưu trữ là giao diện giữa dev và DBA. Hoặc, bạn đang vận chuyển một sản phẩm bán tùy chỉnh và các procs được lưu trữ có thể được người dùng tùy chỉnh. Không có một số cân nhắc như vậy, tôi nghĩ mặc định cho bất kỳ dự án Agile SW nào trong những ngày này sẽ là ORM.

Xem xét tất cả các trường hợp trên, tôi muốn thêm một trường hợp nữa. Sự lựa chọn SP có thể phụ thuộc vào sự lựa chọn của mọi người.

Cá nhân tôi cảm thấy thất vọng khi mọi người đưa logic rất phức tạp vào SP và tôi tin rằng SP như vậy rất phức tạp để duy trì và gỡ lỗi. Thậm chí nhiều trường hợp, chính nhà phát triển phải đối mặt với vấn đề khi gỡ lỗi mã phía sau (nói phần ngôn ngữ) dễ dàng hơn nhiều so với SP.

SP chỉ nên được sử dụng cho các hoạt động đơn giản. Vâng đó là lựa chọn của tôi.

Tôi muốn đề cập đến cả một số vấn đề và vấn đề với các procs được lưu trữ. Chúng tôi sử dụng chúng rộng rãi với LedgerSMB và quy tắc của chúng tôi là, với một vài phần mở rộng rất cụ thể, "nếu đó là một truy vấn, hãy biến nó thành một Proc được lưu trữ."

Lý do của chúng tôi để làm điều này là để tạo điều kiện tái sử dụng truy vấn ngôn ngữ chéo. Không có cách nào tốt hơn để làm điều này một cách trung thực.

Cuối cùng, câu hỏi luôn luôn là chi tiết. Được sử dụng tốt, các thủ tục lưu trữ làm cho mọi thứ dễ dàng hơn nhiều, và sử dụng kém chúng làm cho mọi thứ khó khăn hơn nhiều.

Vì vậy, về phía con.

1. Theo truyền thống được sử dụng, các thủ tục lưu trữ là giòn. Được sử dụng một mình, chúng tạo ra khả năng thêm lỗi vào mã của bạn ở những nơi bạn không mong đợi mà không có lý do nào khác ngoài cú pháp cuộc gọi đã thay đổi. Được sử dụng một mình đây là một chút vấn đề. Có quá nhiều sự gắn kết giữa các lớp và điều này gây ra vấn đề.

2. Có, có thể tiêm sql nội bộ nếu thực hiện bất kỳ sql động. Thật là một điều tồi tệ khi quá tự tin vào lĩnh vực này, và do đó, người ta cần phải có kinh nghiệm đáng kể về an ninh trong lĩnh vực này.

3. Thay đổi giao diện có chút vấn đề với các thủ tục được lưu trữ vì lý do số 1 ở trên nhưng điều này có thể trở thành cơn ác mộng rất lớn nếu có số lượng lớn ứng dụng khách tham gia.

Trên đây là khá khó để từ chối. Chúng xảy ra. Mọi người, pro-SP và anti-SP có lẽ đã có những câu chuyện kinh dị liên quan đến những điều này. Các vấn đề không thể giải quyết được nhưng nếu bạn không chú ý đến chúng, bạn không thể giải quyết chúng (trong LedgerSMB, chúng tôi sử dụng công cụ định vị dịch vụ để tự động xây dựng các cuộc gọi SP trong thời gian chạy, tránh hoàn toàn các vấn đề trên. chỉ, một cái gì đó tương tự có thể được thực hiện cho các db khác).

Về mặt tích cực. Giả sử bạn có thể giải quyết các vấn đề trên, bạn nhận được:

1. Khả năng tăng cường rõ ràng trong các hoạt động thiết lập. Điều này đặc biệt đúng nếu truy vấn của bạn rất lớn hoặc rất linh hoạt. Điều này cũng dẫn đến khả năng kiểm tra nâng cao.

2. Nếu tôi có một trình định vị dịch vụ đã hoạt động trong lĩnh vực này, tôi thấy các thủ tục được lưu trữ tăng tốc độ phát triển vì chúng giải phóng nhà phát triển ứng dụng khỏi các mối quan tâm của db và ngược lại. Điều này có một số khó khăn trong việc làm đúng nhưng nó không khó thực hiện.

3. Truy vấn sử dụng lại.

Ồ và một vài điều bạn gần như không bao giờ nên làm trong SP:

1. logic phi giao dịch. Bạn đã gửi email rằng đơn đặt hàng đã được chuyển đi nhưng giao dịch đã quay trở lại ... hoặc bây giờ bạn đang chờ để tiếp tục cho máy chủ email trực tuyến .... hoặc tệ hơn là bạn quay lại giao dịch của mình chỉ vì bạn không thể tiếp cận máy chủ email ....

2. rất nhiều truy vấn nhỏ được xâu chuỗi lại với nhau, rắc logic logic ....

Bạn làm việc cho ai

Câu trả lời có thể phụ thuộc vào người bạn được tuyển dụng bởi, công ty tư vấn hoặc chính công ty. Những gì tốt nhất cho một công ty thường không phải là tốt nhất cho một công ty tư vấn hoặc nhà cung cấp phần mềm khác. ví dụ: Một công ty thông minh mong muốn có lợi thế vĩnh viễn so với các đối thủ cạnh tranh. Ngược lại, một nhà cung cấp phần mềm muốn có thể diều hâu cùng một giải pháp cho tất cả các doanh nghiệp trong một ngành cụ thể, với chi phí thấp nhất. Nếu họ thành công trong việc này, sẽ không có lợi thế cạnh tranh ròng cho khách hàng.

Trong trường hợp cụ thể này, các ứng dụng đến và đi nhưng rất thường xuyên, cơ sở dữ liệu của công ty tồn tại mãi mãi. Một trong những điều cơ bản mà RDBMS làm là giữ dữ liệu rác không xâm nhập vào cơ sở dữ liệu. Điều này có thể liên quan đến các thủ tục được lưu trữ. Nếu logic là logic tốt và rất khó thay đổi từ năm này sang năm khác, tại sao nó không nên có trong cơ sở dữ liệu, giữ cho nó nhất quán trong nội bộ, bất kể ứng dụng nào được viết để sử dụng cơ sở dữ liệu? Nhiều năm sau, ai đó sẽ có một câu hỏi mà họ muốn hỏi về cơ sở dữ liệu và sẽ có thể trả lời được nếu rác đã bị ngăn không cho vào DB.

Vì vậy, có lẽ điều này có liên quan đến thực tế là DBA của bạn làm việc cho một công ty tư vấn. Họ càng có thể tạo mã, họ càng có thể sử dụng lại mã từ máy khách này sang máy khách khác. Càng có nhiều logic họ có thể kết nối trong ứng dụng của mình, công ty càng kết hôn với nhà cung cấp. Nếu họ để lại một mớ hỗn độn lớn trong quy trình, họ sẽ được trả tiền để dọn dẹp nó, hoặc không bao giờ nhìn thấy mớ hỗn độn đó nữa. Dù bằng cách nào, đó là một chiến thắng cho họ.

Để (nhiều) thảo luận nhiều hơn ở cả hai phía của hàng rào, hãy đọc các cuộc thảo luận tại mã hóa kinh dị . FWIW Tôi nghiêng về phía những người ủng hộ SP.

Rất khó để chuyển đổi nhãn hiệu cơ sở dữ liệu và sử dụng các quy trình được lưu trữ tương tự.

Nhóm của bạn không có DBA và không ai khác muốn làm gì với sql.

Điều này không gì khác hơn là một cuộc thi pissing lập trình v DBA.

IMO nó phụ thuộc. Các thủ tục được lưu trữ có vị trí của chúng, nhưng chúng không phải là một thực tiễn tốt nhất, cũng không phải là thứ cần tránh bằng mọi giá. Một nhà phát triển thông minh biết cách đánh giá đúng một tình huống nhất định và xác định xem một thủ tục được lưu trữ có phải là câu trả lời hay không. Cá nhân tôi là một người hâm mộ sử dụng ORM của một loại nào đó (thậm chí là một loại cơ bản như Linq thô cho Sql) chứ không phải là các thủ tục được lưu trữ trừ khi có thể cho các báo cáo được xác định trước hoặc tương tự nhưng một lần nữa nó thực sự là một trường hợp cụ thể.

Luôn luôn là một vấn đề khiến logic kinh doanh bị tách ra giữa các lớp khác nhau, sử dụng các ngôn ngữ lập trình khác nhau. Theo dõi lỗi hoặc thực hiện thay đổi là cách khó hơn khi bạn phải chuyển đổi giữa các thế giới.

Điều đó nói rằng, tôi biết các công ty làm khá tốt bằng cách đưa tất cả logic kinh doanh vào các gói PL / SQL sống trong cơ sở dữ liệu. Đó không phải là những ứng dụng rất lớn, nhưng cũng không tầm thường; nói 20K-100K LỘC. (PL / SQL phù hợp hơn với loại hệ thống đó so với T-SQL, vì vậy nếu bạn chỉ biết T-SQL, có lẽ bạn đã lắc đầu không tin vào lúc này ...)

Đây là một điểm khác chưa được đề cập:

Các công cụ tạo mã và các công cụ kỹ thuật đảo ngược thực sự không thể đối phó tốt với các thủ tục được lưu trữ. Các công cụ thường không thể nói những gì các Proc làm. Liệu Proc trả lại một kết quả? Vài kết quả? Nó có tìm nạp các kết quả của nó từ một số bảng và bảng tạm thời không? Có phải Proc chỉ là một tuyên bố cập nhật được đóng gói và không trả lại bất cứ điều gì? Nó có trả về một tập kết quả, giá trị trả về và một số "đầu ra giao diện điều khiển" không?

Vì vậy, nếu bạn muốn sử dụng một công cụ để tự động tạo lớp DTO và DAO đối tượng truyền dữ liệu (chẳng hạn như "trình xây dựng dịch vụ" của liferay), bạn không thể dễ dàng làm như vậy.

Hơn nữa, các ORM như Hibernate thực sự không thể hoạt động chính xác khi nguồn dữ liệu là SP. Truy cập dữ liệu là chỉ đọc ở mức tốt nhất.

Lập trình solo, tôi không thể cưỡng lại việc viết các thủ tục lưu trữ.

Tôi đang sử dụng MySQL là chủ yếu. Tôi chưa từng sử dụng cơ sở dữ liệu hướng đối tượng trước đây như PostGreSQL, nhưng những gì tôi có thể làm với SP trong MySQL là trừu tượng hóa cấu trúc bảng một chút. SP của phép tôi để thiết kế những hành động thô sơ, có đầu vào và đầu ra sẽ không thay đổi , ngay cả khi cơ sở dữ liệu bên dưới nó không thay đổi.

Vì vậy, tôi có một thủ tục được gọi là logIn. Khi bạn đăng nhập, bạn luôn chỉ cần vượt qua usernamevà password. Kết quả được truyền lại là số nguyên userId.

Khi logInlà một thủ tục được lưu trữ, bây giờ tôi có thể thêm công việc bổ sung được thực hiện khi đăng nhập xảy ra cùng lúc với đăng nhập ban đầu. Tôi tìm thấy một loạt các câu lệnh SQL với logic nhúng trong một thủ tục được lưu trữ dễ viết hơn so với (gọi môi trường FETCH) -> (lấy kết quả) -> (gọi môi trường FETCH) mà bạn phải thực hiện khi bạn viết phía máy chủ logic của mình.

Tôi cũng muốn chỉ ra rằng các thủ tục được lưu trữ sử dụng thời gian cpu trên máy chủ. Không nhiều, nhưng một số. Một số công việc được thực hiện trong quy trình làm việc có thể được thực hiện trong ứng dụng. Dễ dàng mở rộng lớp ứng dụng hơn lớp dữ liệu.

Tôi đồng ý với Mark rằng cộng đồng đã thực sự tránh xa các thủ tục được lưu trữ từ khá lâu rồi. Mặc dù nhiều điểm mà poster ban đầu nêu ra tại sao chúng ta có thể muốn sử dụng SP có hiệu lực tại một thời điểm, nhưng nó đã khá lâu và, như một poster khác cho biết, môi trường đã thay đổi. Chẳng hạn, tôi nhớ một đối số CHO sử dụng SP 'trở lại trong ngày' là mức tăng hiệu suất đạt được vì kế hoạch thực hiện của chúng được 'biên dịch trước' trong khi SQL động từ mã của chúng tôi phải được 'biên dịch lại' với mỗi lần thực thi. Đây không còn là trường hợp vì các cơ sở dữ liệu chính đã thay đổi, cải thiện, thích nghi, v.v.

Điều đó nói rằng, chúng tôi đang sử dụng SP trên dự án hiện tại của tôi. Lý do đơn giản là vì chúng tôi đang xây dựng các ứng dụng mới trên cơ sở dữ liệu hiện có vẫn hỗ trợ các ứng dụng cũ. Do đó, việc thay đổi lược đồ là rất khó khăn cho đến khi chúng tôi tắt các ứng dụng cũ. Chúng tôi đã đưa ra quyết định có ý thức khi thiết kế các ứng dụng mới của mình dựa trên hành vi và quy tắc cần thiết cho ứng dụng và sử dụng SP để tạm thời giao tiếp với cơ sở dữ liệu theo cách chúng tôi muốn và cho phép SP thích ứng với SQL hiện có . Điều này đi đến điểm của người đăng trước đó rằng SP giúp dễ dàng thực hiện thay đổi ở cấp cơ sở dữ liệu mà không yêu cầu thay đổi mã ứng dụng. Sử dụng SP làm triển khai mẫu Adaptor chắc chắn có ý nghĩa đối với tôi (đặc biệt là với dự án hiện tại của tôi),

Fwiw, chúng tôi có ý định loại bỏ các SP khi lược đồ được cập nhật. Nhưng, như mọi thứ khác trong phát triển công ty, chúng ta sẽ xem điều đó có bao giờ xảy ra không! [cười]

Tôi chỉ muốn làm cho một cái nhìn tổng quan súc tích về cách tôi sẽ khuyên bạn nên sử dụng các thủ tục được lưu trữ. Tôi không nghĩ rằng chúng là một thực hành xấu cả, và giống như những người khác đã nói rằng chúng nên được sử dụng trong các tình huống thích hợp.

Tôi có thể thấy các vấn đề trong đó các quy trình viết cho các ứng dụng khác nhau có thể trở nên khó hiểu về chức năng và tách biệt logic nghiệp vụ của ứng dụng và dẫn đến cơ sở dữ liệu cũng trở nên vô tổ chức và hạn chế hơn.

Do đó, tôi sẽ sử dụng một thủ tục được lưu trữ trong các tác vụ hướng dữ liệu quan hệ cụ thể cho cơ sở dữ liệu. Nói cách khác, nếu có logic được sử dụng cho các hoạt động cơ sở dữ liệu phù hợp với dữ liệu cho bất kỳ ứng dụng nào, một quy trình được lưu trữ có thể được sử dụng để giữ cho dữ liệu được lưu trữ một cách nhất quán (có ý nghĩa). Tôi nghĩ những ví dụ điển hình của việc này là: ghi nhật ký nhất quán, bảo trì nhất quán, làm việc với thông tin nhạy cảm, v.v.

Các tác vụ khác thao tác dữ liệu để phù hợp với nhu cầu của ứng dụng theo mô hình dữ liệu mạnh của cơ sở dữ liệu, tôi nghĩ, sau đó nên được lưu trữ trong một lớp khác có chứa logic nghiệp vụ. Nói tóm lại, thao tác dữ liệu cụ thể của cơ sở dữ liệu về tính nhất quán có thể sử dụng các thủ tục được lưu trữ, trong đó tính nhất quán kéo dài qua mô hình lược đồ toàn vẹn cơ sở dữ liệu.

Các thủ tục được lưu trữ "đối với tôi" phù hợp với các hoạt động "chỉ đọc" của OLAP, sử dụng hiếm.

Đối với các quy tắc nghiệp vụ, các hoạt động đọc / ghi OLTP tôi thích các máy chủ ứng dụng Java. Để dễ mã hóa và càng nhiều càng tốt, giảm tải cpu và bộ nhớ từ các máy chủ db chính. Trong thiết lập này, tất cả các mã trong các máy chủ ứng dụng không khó để xem lại hoặc ghi nhật ký và khả năng mở rộng của nó.

Điều quan trọng đối với tôi là việc gỡ lỗi trong lớp nghiệp vụ dễ dàng hơn so với các thủ tục lưu trữ gỡ lỗi.

Bên cạnh việc phân phối logic kinh doanh một cách không cần thiết và ràng buộc bạn với một nhà cung cấp cơ sở dữ liệu cụ thể, tôi cũng tin tưởng chắc chắn vào việc sử dụng một công nghệ cho những gì nó được dự định. Một cơ sở dữ liệu chỉ là một kho lưu trữ dữ liệu quan hệ. Sử dụng nó để lưu trữ dữ liệu, không có gì khác.

Chọn công cụ của bạn một cách khôn ngoan và bạn sẽ tự cứu mình một thế giới bị tổn thương trong thời gian dài.