การตั้งค่า CLR กลางที่เก็บ CLR โพรซีเดอร์ / ฟังก์ชันที่เก็บไลบรารีสำหรับ procs ที่จัดเก็บภายในในฐานข้อมูลอื่น ๆ ที่จะใช้?

ฉันต้องการใช้รหัสที่ฉันพัฒนาใน C # CLR เพื่อใช้ในฐานข้อมูลทั้งหมดในระบบเพื่อให้ฉันไม่ต้องตั้งค่าให้เชื่อถือได้และเปิด CLR และเก็บรหัสเดียวกันไว้ในแต่ละอัน .

มีวิธีที่ดีที่สุดในการทำเช่นนี้จากมุมมองการบริหารและความปลอดภัย? ฟังก์ชัน CLR นั้นพื้นฐานมากเช่นตัวแบ่งสตริง, การตรวจสอบความถูกต้องของอีเมล, url en / decode, base64 และอื่น ๆ ฉันต้องการเฉพาะ dbo schema ในแต่ละฐานข้อมูลเพื่อให้สามารถเข้าถึงฟังก์ชันได้

1. มีวิธีง่าย ๆ ในการทำเช่นนี้?
2. นอกจากนี้ฉันยังไม่ชัดเจนว่า CLR dll ถูกฝังอยู่หรือไม่และถ้าฉันย้ายฐานข้อมูลมันจะแท็กตามหรือฉันต้องย้าย dll ด้วยเช่นกัน

ขอบคุณ

ที่ บริษัท ของเราเรามีการตั้งค่าที่แน่นอน เมื่อคุณสร้างแอสเซมบลี CLR การแสดงแบบไบนารี่ของแอสเซมบลีจะถูกเก็บไว้ในฐานข้อมูลที่คุณสร้างขึ้นสิ่งนี้ช่วยให้คุณสามารถนำมันไปกับคุณ (และแม้แต่สคริปต์ออก) หากคุณย้ายฐานข้อมูล ณ เวลาใด ๆ

สองสามเดือนหลังศูนย์ข้อมูลของเราถูกน้ำท่วม - เติมเซิร์ฟเวอร์จำนวนมากเต็มไปด้วยน้ำ เมื่อฉันสร้างมันขึ้นมาใหม่ฉันใช้เฉพาะการสำรองข้อมูลของฐานข้อมูลที่ถ่ายเมื่อคืนก่อน จนถึงตอนนี้เราก็ไม่มีปัญหา .. (แตะไม้!)

ฉันไม่แน่ใจว่านี่เป็นสิ่งที่ถูกต้องที่จะทำจากมุมมองด้านความปลอดภัย แต่วิธีที่เราให้สิทธิ์การเข้าถึง CLR procs ฯลฯ คือการสร้างบทบาทภายในฐานข้อมูลที่ใช้ร่วมกันแล้วเพิ่มผู้ใช้จากฐานข้อมูลอื่น ๆ ไปยังบทบาทนั้น จากนั้นบทบาทจะได้รับการเรียกใช้งานบนโปรแกรม CLR

อาจมีปัญหาการเข้าถึงหาก CLR พยายามทำสิ่งต่าง ๆ เช่นทรัพยากรการเข้าถึงภายนอกฐานข้อมูลที่อยู่ภายใน แต่คุณสามารถตั้งค่าการอนุญาตในแอสเซมบลีเมื่อคุณสร้าง ลิงค์ด้านล่างมีข้อมูลเกี่ยวกับการอนุญาตมากกว่าที่ฉันสามารถอธิบายได้ที่นี่:

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

ฉันหวังว่านี่จะช่วยคุณได้

แอสเซมบลีไบนารี่จะถูกจัดเก็บเป็นหยดในฐานข้อมูลดังนั้นจึงมีการดำเนินการทุกที่ที่ฐานข้อมูลดำเนินการ CLR เปิดใช้งานบนอินสแตนซ์เท่านั้น - ไม่มีการตั้งค่าเฉพาะฐานข้อมูลสำหรับสิ่งนั้น

ไม่ว่าในกรณีใดคุณพยายามทำเช่นนี้

(ฉันไม่ได้พยายามโต้เถียงฉันแค่อยากได้ยินแรงจูงใจที่เกี่ยวข้องเพราะบางทีปัญหาอาจแก้ไขได้ในวิธีที่แตกต่างที่ตรงกับความต้องการของคุณ)

ไม่มีวิธีการทำเช่นนี้ได้อย่างง่ายดายยกเว้นการประกอบในฐานข้อมูลที่ใช้ร่วมกัน

ที่กล่าวว่าฉันคิดว่ามันเป็นประโยชน์ที่จะโอบกอดสถาปัตยกรรมเป็นศูนย์กลางฐานข้อมูลเว้นแต่จะมีสถานการณ์เฉพาะที่มีเหตุผลที่น่าสนใจมากในการรวมศูนย์ เหตุผลคือการวางแอสเซมบลี (หรือสิ่งใดสำหรับเรื่องนั้น) นอกฐานข้อมูลสร้างการอ้างอิงในสภาพแวดล้อมของคุณ นี่เป็นวิธีที่ตรงกันข้ามกับที่ Microsoft กำลังสร้างขึ้นด้วยฐานข้อมูลที่มีอยู่ซึ่งเริ่มต้นใน SQL Server 2012

• เมื่อคุณเริ่มต้องการใช้คุณลักษณะเช่นการจำลองแบบหรือการทำคลัสเตอร์การพึ่งพานี้อาจเพิ่มความซับซ้อนจำนวนมากให้กับการปรับใช้ แต่ยังรวมถึงการแก้ไขปัญหาและขั้นตอนการเข้าแทนที่

• สถาปัตยกรรมนี้มีความชัดเจนน้อยกว่าสำหรับผู้ที่ไม่คุ้นเคยกับระบบ (เช่นมีการค้นพบตัวเองน้อยลงและบันทึกเอกสารด้วยตนเองน้อยลง)

• หากคุณต้องการความปลอดภัยที่แตกต่างกันในฐานข้อมูลที่แตกต่างกันหรืออะไรก็ตามที่เกี่ยวข้องกับการเปลี่ยนแปลงคุณอยู่ในโลกที่เจ็บปวด

• หากฐานข้อมูลเหล่านี้ถูกปรับใช้กับลูกค้า (ดูเหมือนว่าพวกเขาจะไม่เป็น แต่ฉันจะพูดแบบนี้เพื่อความสมบูรณ์) ซึ่งจะเพิ่มความซับซ้อนให้กับขั้นตอนการปรับใช้การบำรุงรักษาและการแก้ไขปัญหา

• เนื่องจากฐานข้อมูลทั้งหมดจะใช้รหัสนี้ร่วมกันหากมีข้อผิดพลาดเกิดขึ้น (หรือแก้ไข!) สิ่งนี้อาจทำให้แอปพลิเคชันทั้งหมดที่ใช้ฐานข้อมูลนั้นเสียหาย การทดสอบหน่วยที่ครอบคลุมจะต้องแน่นอน

หากคุณมีฐานข้อมูลหลายอย่างที่ต้องการฟังก์ชันการทำงานเดียวกันมีวิธีอื่นในการลดจำนวนการทำซ้ำที่เกี่ยวข้องซึ่งฉันถือว่าเป็นจุดของการฝึก แม้แต่ชุดประกอบ CLR ที่ค่อนข้างซับซ้อนจะไม่ใช้พื้นที่เก็บข้อมูลทางกายภาพมากนักเมื่อเทียบกับข้อมูลในฐานข้อมูล (เกือบตลอดเวลา) ดังนั้นฉันจึงไม่เห็นว่าเป็นอาร์กิวเมนต์ที่ถูกต้องเว้นแต่คุณจะมีฐานข้อมูลขนาดเล็กจำนวนมากที่ต้องการสิ่งนี้ การชุมนุม

สิ่งที่คุณสามารถทำได้คือปรับเปลี่ยนส่วนอื่น ๆ ของกระบวนการปรับใช้สำหรับฐานข้อมูลเหล่านี้เพื่อลดความซ้ำซ้อนของแหล่งที่มา ตัวอย่างเช่นสร้างและปรับใช้ชุดประกอบจากตำแหน่งทั่วไปของรหัส CLR ในการควบคุมแหล่งที่มา หรือสร้างสคริปต์ที่ปรับใช้แอสเซมบลีเดียวกันกับฐานข้อมูล ทำให้ส่วนนี้เป็นไปโดยอัตโนมัติให้มากที่สุดและจะไม่เป็นเรื่องใหญ่

ฉันยอมรับว่าสิ่งที่ฉันแนะนำคือการแลกเปลี่ยนเพราะจะยังมีการทำซ้ำ แต่จะต้องมีความสมดุลกับเชิงลบที่เกี่ยวข้องกับการใช้งานสถาปัตยกรรมที่ไม่เป็นไปตามมาตรฐานที่กำหนด มีเพียงคุณเท่านั้นที่สามารถตัดสินใจได้ว่าอะไรเหมาะสมกับสภาพแวดล้อมของคุณ

เนื่องจากคำตอบอีกสองข้อถูกต้องสถานะแอสเซมบลีจะถูกโหลดลงในฐานข้อมูลเฉพาะและไม่ได้ทั้งระบบ (แม้ว่าฉันค่อนข้างแน่ใจว่าassembly_idค่านั้นเป็นระบบที่ไม่ซ้ำกัน) ซึ่งหมายความว่าพวกเขาได้รับการสำรองและกู้คืนโดยมีฐานข้อมูลแต่ละรายการที่พวกเขาโหลดเข้ามา

นอกจากนี้การตั้งค่าenabled/ (ผ่าน) ยังใช้กับทั้งระบบ ในฐานะที่เป็นข้อความด้านการตั้งค่านั้นใช้สำหรับการทำงานของ CLR ที่ผู้ใช้สร้างขึ้นเท่านั้น CLR ในความหมายทั่วไปเปิดใช้งานเสมอเนื่องจากฟังก์ชันการทำงานในตัวบางอย่างขึ้นอยู่กับมันdisabledCLR Integrationsp_configure

ดังที่กล่าวไว้ในขณะที่อีกสองคำตอบที่นี่จะให้คะแนนที่ถูกต้อง แต่คะแนนเหล่านั้นไม่ได้ระบุไว้เฉพาะ SQLCLR และไม่มีการกล่าวถึงปัจจัยในการตัดสินใจนี้ที่เฉพาะเจาะจงกับรหัส SQLCLR มีปัญหาหน่วยความจำที่ต้องพิจารณาหากคุณปรับใช้รหัสในแต่ละฐานข้อมูล (สมมติว่าคุณมีฐานข้อมูลจำนวนมาก), ปัญหาการช่วงชิงทรัพยากรที่อาจเกิดขึ้น, ปัญหาเกี่ยวกับความปลอดภัยที่อาจเกิดขึ้นเป็นต้น

ฉันได้เตรียมสิ่งที่ควรเป็นรายการสิ่งที่ต้องคำนึงถึงโดยเฉพาะอย่างยิ่งสำหรับรหัส SQLCLR เมื่อตัดสินใจระหว่างฐานข้อมูลส่วนกลางกับการปรับใช้ฐานข้อมูลแต่ละรายการ แทนที่จะทำซ้ำรายการที่นี่โปรดดูคำตอบต่อไปนี้ (ที่นี่ใน DBA.SE):

วิธีการใช้ฟังก์ชั่น CLR ให้ดีขึ้นจากมุมมองประสิทธิภาพ (ทำซ้ำภายในแต่ละฐานข้อมูลหรือมีฟังก์ชั่นทั่วไป)

นอกจากนี้ในบันทึกที่เกี่ยวข้องผมจะถามว่าทำไมฐานข้อมูลใด ๆ TRUSTWORTHY ONจะถูกตั้งค่าให้ ฟังก์ชันการทำงานที่ระบุไว้ในคำถาม (เช่น "ตัวแบ่งสตริงการตรวจสอบอีเมล url en / decode, base64 ฯลฯ ") เป็นไปได้ทั้งหมดภายในSAFEแอสเซมบลี คุณไม่ควรใช้ค่าEXTERNAL_ACCESSหรือUNSAFEperission_set เว้นแต่จำเป็นจริงๆ และถ้าจำเป็นสำหรับบางฟังก์ชั่นบางอย่างฟังก์ชันเหล่านั้นควรอยู่ในแอสเซมบลีที่แยกต่างหากซึ่งมีSAFEรหัสเท่านั้นเช่นฟังก์ชันสเกลาร์ใด ๆ ที่ไม่เข้าถึงข้อมูลและถูกทำเครื่องหมายว่าIsDeterministic = trueจะสามารถใช้ประโยชน์จากประสิทธิภาพการเป็น สามารถมีส่วนร่วมในแผนขนาน