هل تُفضل إجراءات CLR المخزنة على إجراءات TSQL المخزنة في SQL 2005+؟

Question

وجهة نظري الحالية هي لا، أفضّل إجراءات Transact SQL المخزنة لأنها أخف وزنًا و(ربما) خيارًا أعلى أداءً، بينما تسمح إجراءات CLR للمطورين بالتعرض لجميع أنواع الأذى.

ولكن في الآونة الأخيرة كنت بحاجة إلى تصحيح بعض عمليات TSQL المخزنة بشكل سيء للغاية.كالعادة، وجدت العديد من المشكلات بسبب عدم وجود خبرة حقيقية للمطور الأصلي في TSQL، فقد ركزوا على ASP.NET / C#.

لذلك، فإن استخدام إجراءات CLR سيوفر أولاً مجموعة أدوات مألوفة لهذا النوع من المطورين، وثانيًا، ستكون مرافق التصحيح والاختبار أكثر قوة (أي Visual Studio بدلاً من SQL Management Studio).

سأكون مهتمًا جدًا بسماع تجربتك لأنه يبدو أنه ليس خيارًا بسيطًا.

Answer 1

هناك أماكن لكل من T-SQL وCLR المكتوبة جيدًا والمدروسة جيدًا.إذا لم يتم استدعاء بعض الوظائف بشكل متكرر وإذا كانت تتطلب إجراءات موسعة في SQL Server 2000، فقد يكون CLR خيارًا.قد يكون أيضًا تشغيل أشياء مثل الحساب بجوار البيانات أمرًا جذابًا.لكن حل مشكلة المبرمجين السيئين من خلال إدخال تكنولوجيا جديدة يبدو فكرة سيئة.

Answer 2

ليس المقصود من إجراءات CLR المخزنة أن تحل محل الاستعلامات المستندة إلى المجموعة.إذا كنت بحاجة إلى الاستعلام عن قاعدة البيانات، فستظل بحاجة إلى وضع SQL في كود CLR الخاص بك، تمامًا كما لو كان مضمنًا في كود عادي.وهذا من شأنه أن يكون مضيعة للجهد.

إجراءات CLR المخزنة مخصصة لأمرين رئيسيين:1) التفاعل مع نظام التشغيل، مثل القراءة من ملف أو إسقاط رسالة في MSMQ، و2) إجراء عمليات حسابية معقدة، خاصة عندما يكون لديك بالفعل رمز مكتوب بلغة .NET لإجراء الحساب.

Answer 3

تهدف استضافة CLR داخل SQL Server إلى منح مطوري قواعد البيانات خيارات أكثر مرونة في كيفية سعيهم لإنجاز المهام.كما ذكر الآخرون، تعتبر لغة SQL رائعة للعمليات والتعديلات مجموعات من البيانات.من المحتمل أن يخبرك أي شخص قام بتطوير تطبيقات كبيرة واسعة النطاق باستخدام قواعد عمل/مجال معقدة - إن محاولة فرض بعض هذه القواعد باستخدام SQL خالص (في بعض الأحيان في استعلام ماكرو واحد) يمكن أن تصبح كابوسًا حقًا.

هناك فقط بعض المهام التي يتم التعامل معها بشكل أفضل بطريقة إجرائية أو بطريقة OO.من خلال الحصول على خيار استخدام كود .NET لتحليل تسلسل المنطق، يمكن أن تصبح عمليات الاستعلام أسهل في القراءة والتصحيح.بعد استخدام عمليات CLR المخزنة، يمكنني أن أخبرك أن التنقل باستخدام مصحح الأخطاء يجعل من السهل متابعة ما يحدث على مستوى قاعدة البيانات.

مثال واحد فقط، نستخدم بشكل متكرر عمليات CLR المخزنة هنا باعتبارها "بوابة" لاستعلامات البحث الديناميكية.قل طلب بحث يمكن أن يحتوي على ما يصل إلى 30 معلمة بحث مختلفة.من الواضح أن المستخدمين لا يستخدمون كل هذه المعلمات الثلاثين، لذا فإن بنية البيانات التي تم تمريرها ستحتوي على 30 معلمة ولكن معظمها DBNULL.جانب العميل لديه لا خيار لإنشاء بيان ديناميكي، لأسباب أمنية واضحة.يتم إنشاء البيان الديناميكي الناتج داخليًا دون خوف من "الإضافات" الخارجية.

Answer 4

بشكل عام، يمكنك استخدام CLR إذا كان لديك شيء لا يحتاج إلى التفاعل مع قاعدة البيانات كثيرًا.لنفترض أنك تقوم بتحليل قيمة ما أو فك تشفيرها.من الأسهل القيام بذلك في CLR ثم إرجاع القيمة.

إن محاولة إجراء استعلام مقنع في CLR ليس هو الحل الأمثل.

راجع للشغل هذا لم يتغير في عام 2008 سواء.

Answer 5

أعتقد أن هذين الاثنين ليسا متساويين..مناسبة للوقوف في مواجهة بعضها البعض.
من المفترض أن يؤدي تكامل CLR إلى التخلص التدريجي من "الإجراءات المخزنة الموسعة" في الماضي. لدينا بعض هذه الأشياء في أماكن عملنا..بشكل أساسي كتل المعالجة/المنطق عبر بيانات SQL التي كان من الصعب جدًا/المستحيل القيام بها عبر إجراءات DB المخزنة التقليدية/T SQL.لذلك قاموا بكتابتها كإجراءات مخزنة ممتدة في مكتبات الارتباط الحيوي (DLL) الخاصة بـ C++ والتي يمكن استدعاؤها بالمثل.لقد تم الآن التخلص التدريجي منها وأصبح تكامل CLR هو البديل

• الإجراءات المخزنة في قاعدة البيانات:إذا كان من الممكن القيام بذلك في عمليات T SQL Stored، فافعل ذلك.
• إجراءات CLR المخزنة:إذا كان المنطق معقدًا جدًا أو مملاً بحيث لا يمكن تنفيذه عبر T SQL ...إذا كان الأمر سيتطلب عددًا أقل من أسطر كود CLR لمعالجته (معالجة السلسلة، أو الفرز المعقد/المخصص أو التصفية، وما إلى ذلك) فاستخدم هذا الأسلوب.

Answer 6

بصرف النظر عن الوصول إلى نظام الملفات (حيث تتمتع عمليات CLR بميزة واضحة جدًا) سأستخدم عمليات T-SQL.إذا كانت لديك حسابات معقدة بشكل خاص، فيمكنك وضع هذه القطعة في CLR وظيفة وقم باستدعاء هذا من داخل proc الخاص بك (udf هو المكان الذي وجدت فيه أن تكامل CLR يتألق حقًا).ثم تحصل على فوائد تكامل CLR لهذا الجزء المعين من مهمتك مع الاحتفاظ بأكبر قدر ممكن من منطق الإجراءات المخزن في قاعدة البيانات قدر الإمكان.

Answer 7

بالنظر إلى ما قلته، أفضل أن تقوم بتدريب المطورين بشكل صحيح على t-SQl وقواعد البيانات بشكل عام بدلاً من السماح لهم بإحداث ضرر أكبر بكثير للأداء من خلال السماح لهم بالقيام بمهام t-sql في CLRs.يستخدم المطورون الذين لا يفهمون قواعد البيانات ذلك كذريعة لتجنب القيام بالأشياء بالطريقة الأفضل لأداء قاعدة البيانات لأنهم يريدون اتباع ما يعتبرونه الطريق الأسهل.

Answer 8

يتعلق الأمر دائمًا بالأداة المناسبة للمهمة، لذلك يعتمد الأمر حقًا على ما تحاول تحقيقه.

ومع ذلك، كقاعدة عامة، أنت على حق في أن عمليات CLR لديها حمل أكبر ولن تنفذ أبدًا عمليات محددة مثل T-SQL.إرشاداتي هي القيام بكل ذلك في T-SQL ما لم يصبح ما تحتاجه معقدًا للغاية في T-SQL.ثم حاول بجدية أكبر أن يعمل أسلوب T-SQL.:-)

تعتبر عمليات CLR رائعة ولها مكانها، لكن استخدامها يجب أن يكون الاستثناء وليس القاعدة.

Answer 9

كتب SQL Server عبر الإنترنت صفحة حول هذا الموضوع يسرد هذه الفوائد:

• نموذج برمجة أفضل. تعد لغات .NET Framework أكثر ثراءً في كثير من النواحي من Transact-SQL، حيث تقدم بنيات وإمكانات لم تكن متوفرة من قبل لمطوري SQL Server.يمكن للمطورين أيضًا الاستفادة من قوة مكتبة .NET Framework، التي توفر مجموعة واسعة من الفئات التي يمكن استخدامها لحل مشكلات البرمجة بسرعة وكفاءة.

• تحسين السلامة والأمن. يتم تشغيل التعليمات البرمجية المُدارة في بيئة تشغيل لغة عامة، يستضيفها محرك قاعدة البيانات.يستفيد SQL Server من ذلك لتوفير بديل أكثر أمانًا للإجراءات المخزنة الموسعة المتوفرة في الإصدارات السابقة من SQL Server.

• القدرة على تحديد أنواع البيانات والوظائف المجمعة. الأنواع المعرفة من قبل المستخدم والتجميعات المعرفة من قبل المستخدم هما كائنان جديدان لقاعدة البيانات المُدارة مما يعمل على توسيع إمكانيات التخزين والاستعلام في SQL Server.

• تبسيط التنمية من خلال بيئة موحدة. تم دمج تطوير قاعدة البيانات في الإصدارات المستقبلية من بيئة تطوير Microsoft Visual Studio .NET.يستخدم المطورون نفس الأدوات لتطوير وتصحيح كائنات قاعدة البيانات والبرامج النصية التي يستخدمونها لكتابة مكونات وخدمات .NET Framework للطبقة المتوسطة أو طبقة العميل.

• إمكانية تحسين الأداء وقابلية التوسع. في العديد من المواقف، توفر نماذج التجميع والتنفيذ للغة .NET Framework أداءً محسنًا عبر Transact-SQL.

Answer 10

لقد واجهنا موقفًا مع وظيفة CLR تم استدعاؤها آلاف المرات في عملية SQL عادية.كانت هذه عملية لاستيراد البيانات من نظام آخر.قامت الوظيفة بالتحقق من صحة البيانات والتعامل مع القيم الخالية بشكل جيد.

إذا أجرينا العملية في TSQL، فستنتهي العملية في حوالي 15 ثانية.إذا استخدمنا وظيفة CLR، تنتهي العملية خلال 20 إلى 40 دقيقة.بدت وظيفة CLR أكثر أناقة، ولكن بقدر ما يمكننا أن نقول، كانت هناك نتيجة لبدء التشغيل لكل استخدام لوظيفة CLR.لذا، إذا كان لديك عملية كبيرة تم إجراؤها باستخدام دالة CLR واحدة، فلا بأس بذلك نظرًا لأن وقت بدء التشغيل صغير مقارنة بوقت العملية.أو إذا قمت باستدعاء وظيفة CLR لعدد بسيط من المرات، فسيكون إجمالي وقت بدء التشغيل لجميع استدعاءات الوظيفة صغيرًا.ولكن كن حذرا من الحلقات.

أيضًا، من أجل قابلية الصيانة، من الأفضل ألا يكون لديك لغات أكثر مما تحتاج إليه حقًا.

Answer 11

أود أن أضيف سببين لاستخدام CLR ربما لم يتم ذكرهما.

• استبدال وتوسيع وظائف الاستعلام الأساسية وغير الاستعلامية والعددية SQL.
  أ) يمكن دمج الإبلاغ عن الأخطاء والتنبيهات بناءً على متطلبات محددة.ب) تحديد مستويات التصحيح بسهولة.ج) تمكين طريقة أسهل للتفاعل مع خوادم SQL الأجنبية
• انقل التعليمات البرمجية القديمة إلى بيئة مُدارة.

Answer 12

لقد نشرت الإجابة التالية على سؤال مماثل: الاستفادة من SQL Server CLR.سأضيف هنا أن لغة C# / VB.net / إلخ هي لغة يشعر الشخص براحة أكبر معها مقارنة بـ T-SQL لا يكون سببًا لاستخدام SQLCLR عبر T-SQL.إذا كان شخص ما لا يعرف كيفية إنجاز شيء ما في T-SQL، فاطلب أولاً المساعدة في العثور على حل T-SQL.إذا واحد غير موجود، ثم اذهب إلى طريق CLR.

---

يعد تكامل SQLCLR / CLR داخل SQL Server مجرد أداة أخرى للمساعدة في حل مشكلات معينة (وليس كلها).هناك بعض الأشياء التي تقوم بها بشكل أفضل مما يمكن القيام به في T-SQL الخالصة، وهناك بعض الأشياء التي لا يمكن القيام بها إلا عبر SQLCLR.لقد كتبت مقالة لـ SQL Server Central، السلم إلى مستوى SQLCLR 1:ما هو SQLCLR؟ (يلزم التسجيل المجاني لقراءة المقالات هناك)، وهذا يجيب على هذا السؤال.الأساسيات هي (راجع المقالة المرتبطة للحصول على التفاصيل):

• وظائف جدول التدفق (sTVF)
• SQL الديناميكي (ضمن الوظائف)
• وصول أفضل إلى الموارد الخارجية / استبدال xp_cmdshell
  • تمرير البيانات أسهل
  • يعد الحصول على أعمدة متعددة من مجموعة النتائج أمرًا أسهل
  • لا توجد تبعيات خارجية (على سبيل المثال.7zip.exe)
  • أمان أفضل عبر انتحال الشخصية
• القدرة على موضوع متعدد
• معالجة الأخطاء (ضمن الوظائف)
• المجاميع المخصصة
• أنواع مخصصة
• تعديل الحالة (داخل الوظيفة وبدونها OPENQUERY / OPENROWSET)
• تنفيذ إجراء مخزن (للقراءة فقط؛داخل وظيفة وبدون OPENQUERY / OPENROWSET)
• أداء (ملحوظة: هذا هو لا يعني في جميع الحالات ولكن بالتأكيد في بعض الحالات حسب نوع العملية وتعقيدها)
• يمكن التقاط الإخراج (أي.ما يتم إرساله إلى علامة تبويب الرسائل في SSMS) (على سبيل المثال. PRINT و RAISERROR مع خطورة = 0 إلى 10)--لقد نسيت أن أذكر هذا في المقال؛-).

هناك شيء آخر يجب مراعاته وهو أنه في بعض الأحيان يكون من المفيد أن تكون قادرًا على مشاركة التعليمات البرمجية بين التطبيق وقاعدة البيانات بحيث يكون لدى قاعدة البيانات نظرة ثاقبة على منطق عمل معين دون الحاجة إلى إنشاء شاشات مخصصة داخلية فقط للوصول إلى رمز التطبيق هذا.على سبيل المثال، لقد عملت على نظام يقوم باستيراد ملفات البيانات من العملاء واستخدام تجزئة مخصصة لمعظم الحقول وحفظ تلك القيمة في الصف في قاعدة البيانات.سمح ذلك بتخطي الصفوف بسهولة عند استيراد بياناتها مرة أخرى حيث سيقوم التطبيق بتجزئة القيم من ملف الإدخال ومقارنتها بقيمة التجزئة المخزنة في الصف.إذا كانت هي نفسها، فسنعرف على الفور أنه لم يتغير أي من الحقول، لذلك انتقلنا إلى الصف التالي، وكانت مقارنة INT بسيطة.لكن تلك الخوارزمية الخاصة بإجراء التجزئة كانت موجودة فقط في كود التطبيق، لذا سواء كان ذلك لتصحيح أخطاء حالة العميل أو البحث عن طرق لتفريغ بعض المعالجة إلى الخدمات الخلفية عن طريق وضع علامة على الصفوف التي تحتوي على حقل واحد على الأقل مع التغييرات (التغييرات القادمة من تطبيقنا بدلاً من البحث عن التغييرات في ملف استيراد أحدث)، لم يكن هناك ما يمكنني فعله.كان من الممكن أن تكون هذه فرصة عظيمة للحصول على جزء بسيط من منطق الأعمال في قاعدة البيانات، حتى لو لم يكن للمعالجة العادية؛إن وجود ما يرقى إلى قيمة مشفرة في قاعدة البيانات مع عدم القدرة على فهم معناها يجعل حل المشكلات أمرًا صعبًا للغاية.

إذا كنت مهتمًا برؤية بعض هذه الإمكانات أثناء العمل دون الحاجة إلى كتابة أي تعليمات برمجية، فإن الإصدار المجاني من SQL # (الذي أنا مؤلفه) يحتوي على وظائف RegEx، والتجميعات المخصصة (UDAs)، والأنواع المخصصة (UDTs)، وما إلى ذلك.