Thiết lập thư viện lưu trữ thủ tục / hàm lưu trữ CLR trung tâm cho các procs được lưu trữ nội bộ trong các cơ sở dữ liệu khác để sử dụng?

Tôi muốn sử dụng mã mà tôi đã phát triển trong C # CLR để được sử dụng trong tất cả các cơ sở dữ liệu trên hệ thống để tôi không phải đặt từng mã đáng tin cậy và bật CLR và giữ một bó mã giống nhau trong mỗi cơ sở dữ liệu .

Có cách nào tốt nhất để làm điều này từ quan điểm hành chính và an ninh? Các hàm CLR rất cơ bản như bộ ngắt chuỗi, xác thực email, url en / decode, base64, v.v. Tôi chỉ muốn lược đồ dbo trong mỗi cơ sở dữ liệu có thể truy cập các hàm.

1. Có cách nào đơn giản để làm điều này?
2. Ngoài ra tôi không rõ liệu dll CLR có được nhúng hay không và nếu tôi di chuyển cơ sở dữ liệu, nó sẽ gắn thẻ hoặc tôi cũng phải di chuyển dll.

Cảm ơn

Tại công ty chúng tôi, chúng tôi có thiết lập chính xác. Khi bạn tạo một cụm CLR, một biểu diễn nhị phân của cụm được lưu trữ trong cơ sở dữ liệu mà bạn tạo ra. Điều này cho phép bạn mang nó theo (và thậm chí cả kịch bản ra) nếu bạn di chuyển cơ sở dữ liệu bất cứ lúc nào.

Một vài tháng trước, trung tâm dữ liệu của chúng tôi đã bị ngập lụt - làm đầy một số máy chủ đầy nước. Khi tôi xây dựng lại chúng, tôi chỉ sử dụng các bản sao lưu của db đã được lấy vào đêm hôm trước. Cho đến nay chúng tôi không có vấn đề gì .. (chạm gỗ!)

Tôi không chắc liệu đây có phải là điều đúng đắn từ góc độ bảo mật hay không, nhưng cách chúng tôi cấp quyền truy cập vào procs CLR, v.v. là tạo vai trò trong cơ sở dữ liệu dùng chung, sau đó thêm người dùng từ cơ sở dữ liệu khác vào vai trò đó. Vai trò này sau đó được cấp thực thi trên các procs CLR.

Có thể có các vấn đề truy cập nếu CLR đang cố gắng thực hiện những việc như tài nguyên truy cập bên ngoài cơ sở dữ liệu mà nó được chứa trong đó nhưng bạn có thể đặt quyền trên cụm khi bạn tạo. Liên kết dưới đây có nhiều thông tin hơn về các quyền mà tôi có thể giải thích ở đây:

http://msdn.microsoft.com/en-us/l Library / ms345101.aspx

Tôi hy vọng rằng điều này sẽ giúp bạn.

Nhị phân lắp ráp được lưu trữ dưới dạng một đốm màu trong cơ sở dữ liệu, vì vậy nó được mang theo bất cứ nơi nào cơ sở dữ liệu đi. CLR chỉ được bật trong trường hợp - không có cài đặt dành riêng cho cơ sở dữ liệu nào cho việc đó.

Trong mọi trường hợp, tại sao bạn cố gắng làm điều này?

(Tôi không cố gắng tranh luận; tôi chỉ muốn nghe những động cơ liên quan, bởi vì có lẽ vấn đề có thể được giải quyết theo một cách khác đáp ứng nhu cầu của bạn.)

Không có cách nào để thực hiện điều này một cách dễ dàng, ngoại trừ việc đưa tổ hợp vào cơ sở dữ liệu dùng chung.

Điều đó nói rằng, tôi sẽ nghĩ rằng sẽ thuận lợi khi nắm lấy kiến ​​trúc tập trung vào cơ sở dữ liệu, trừ khi có một tình huống cụ thể có lý do rất thuyết phục để tập trung. Lý do tại sao việc đặt hội đồng (hoặc bất cứ điều gì cho vấn đề đó) bên ngoài cơ sở dữ liệu sẽ tạo ra sự phụ thuộc trong môi trường của bạn. Đây chính xác là cách tiếp cận ngược lại mà Microsoft đang hướng tới với Cơ sở dữ liệu có chứa bắt đầu từ SQL Server 2012.

• Khi bạn bắt đầu cần sử dụng các tính năng như sao chép hoặc phân cụm, sự phụ thuộc này có thể có khả năng tăng thêm độ phức tạp rất lớn cho việc triển khai, mà còn để khắc phục sự cố và quy trình chuyển đổi dự phòng.

• Kiến trúc này ít rõ ràng hơn đối với những người không quen thuộc với hệ thống (nghĩa là nó ít tự khám phá hơn và ít tự ghi lại tài liệu hơn).

• Nếu bạn cuối cùng yêu cầu bảo mật khác nhau trong các cơ sở dữ liệu khác nhau hoặc bất kỳ điều gì liên quan đến biến thể, bạn sẽ ở trong một thế giới bị tổn thương.

• Nếu các cơ sở dữ liệu này được triển khai cho khách hàng (nghe có vẻ như không có, nhưng tôi sẽ nói điều này cho đầy đủ), điều này sẽ làm tăng thêm sự phức tạp cho quy trình triển khai, bảo trì và xử lý sự cố.

• Vì tất cả các cơ sở dữ liệu sẽ chia sẻ mã này, nếu có bất kỳ lỗi nào được đưa ra (hoặc đã sửa!), Điều này có khả năng phá vỡ tất cả các ứng dụng dựa trên cơ sở dữ liệu. Kiểm tra đơn vị toàn diện sẽ là một phải tuyệt đối.

Nếu bạn có một số cơ sở dữ liệu cần cùng chức năng, có nhiều cách khác để giảm số lượng sao chép liên quan, mà tôi cho là điểm của bài tập. Ngay cả một hội đồng CLR khá phức tạp cũng sẽ không chiếm nhiều dung lượng lưu trữ vật lý so với dữ liệu trong cơ sở dữ liệu (hầu như luôn luôn), vì vậy tôi không thấy đó là một đối số hợp lệ trừ khi bạn có hàng ngàn cơ sở dữ liệu nhỏ cần điều này hội,, tổ hợp.

Những gì bạn có thể làm là sửa đổi các phần khác của quy trình triển khai cho các cơ sở dữ liệu này để giảm trùng lặp nguồn. Ví dụ: xây dựng và triển khai lắp ráp từ vị trí phổ biến của mã CLR trong kiểm soát nguồn. Hoặc, tạo một tập lệnh triển khai lắp ráp tương tự vào cơ sở dữ liệu. Tự động hóa phần này của mọi thứ càng nhiều càng tốt, và nó sẽ không phải là một vấn đề lớn.

Tôi đồng ý rằng những gì tôi đề xuất là một sự đánh đổi, bởi vì vẫn sẽ có một số trùng lặp, nhưng điều đó phải được cân bằng với những tiêu cực liên quan đến việc thực hiện một kiến ​​trúc không tuân theo tiêu chuẩn quy định. Chỉ có bạn mới có thể quyết định những gì phù hợp với môi trường của bạn.

Như hai câu trả lời khác nêu chính xác, Các hội đồng được tải vào một cơ sở dữ liệu cụ thể và không phải là toàn hệ thống (mặc dù tôi khá chắc chắn rằng assembly_idgiá trị này là toàn hệ thống duy nhất). Điều này có nghĩa là chúng được sao lưu và khôi phục, với mỗi cơ sở dữ liệu mà chúng được tải vào.

Ngoài ra, enabled/ disabledcài đặt của CLR Integration(thông qua sp_configure) là toàn hệ thống. Là một lưu ý phụ, cài đặt đó chỉ dành cho chức năng CLR do người dùng tạo ; CLR theo nghĩa chung luôn được bật vì chức năng tích hợp nhất định phụ thuộc vào nó.

Điều đó nói rằng, trong khi hai câu trả lời khác ở đây thực hiện các điểm hợp lệ, thì những điểm đó không dành riêng cho SQLCLR và không có đề cập đến các yếu tố trong việc đưa ra quyết định này dành riêng cho mã SQLCLR. Có các vấn đề về bộ nhớ để xem xét nếu bạn triển khai mã cho từng cơ sở dữ liệu riêng lẻ (giả sử bạn có nhiều cơ sở dữ liệu), các vấn đề tranh chấp tài nguyên tiềm năng, các vấn đề liên quan đến bảo mật tiềm năng, v.v.

Tôi đã cung cấp những gì cần phải là một danh sách toàn diện những điều cần lưu ý, đặc biệt đối với mã SQLCLR, khi quyết định giữa cơ sở dữ liệu tập trung so với triển khai cơ sở dữ liệu riêng lẻ. Thay vì sao chép danh sách ở đây, vui lòng xem câu trả lời sau (cũng ở đây trên DBA.SE):

Làm cách nào để sử dụng tốt hơn Chức năng CLR từ quan điểm hiệu suất (lặp lại bên trong mỗi DB hoặc có chức năng chung)?

Ngoài ra, trên một lưu ý liên quan, tôi sẽ hỏi tại sao bất kỳ cơ sở dữ liệu nào đang được đặt thành TRUSTWORTHY ON. Các chức năng được ghi chú trong Câu hỏi (tức là "bộ ngắt chuỗi, xác thực email, en / giải mã url, base64, v.v.") đều có thể trong một SAFEHội đồng. Bạn không nên sử dụng các giá trị EXTERNAL_ACCESShoặc UNSAFEperission_set trừ khi thực sự cần thiết. Và nếu cần thiết cho một số chức năng, thì những chức năng đó phải ở trong một Hội đồng riêng biệt chỉ chứa SAFEmã sao cho mọi hàm vô hướng không truy cập dữ liệu và được đánh dấu là IsDeterministic = truesẽ có thể sử dụng lợi ích hiệu suất của việc có khả năng tham gia các kế hoạch song song.