حجم SqlParameter - الآثار السلبية للضبط على الحد الأقصى للحجم؟

Question

لدي SqlCommand وأريد الاتصال بـ Preparation() الخاص به CommandType = Text (it لا تستطيع يكون إجراء مخزن).وللقيام بذلك، أحتاج إلى تعيين سمة الحجم على المعلمات لتكون غير صفرية وإلا فسيتم طرح استثناء.هل هناك أي آثار سلبية من ضبط الحجم على جميع المعلمات إلى أقصى حجم ممكن حتى لو كان حجم القيم الفعلية لن يقترب من ذلك أبدًا؟هل هناك طريقة أفضل للقيام بذلك؟

Answer 1

أعتقد أن التأثير الجانبي السلبي الوحيد المحتمل لفعل شيء كهذا سيكون تكلفة تخصيص الذاكرة للمعلمات.

نظرًا لأنك تتصل بـ "Prepare ()" أعتقد أنك تخطط لاستخدام SqlCommand عدة مرات مقابل نفس SqlConnection الذي يقترح قسمًا منفصلاً من التعليمات البرمجية حيث من المحتمل استخدامه (إذا تم إغلاق الاتصال لأمر مُجهز ، يجب إعادة إرسال نص الأمر إلى الخادم عند الاستخدام التالي).

إذا كنت تعرف طبيعة المعلمات الخاصة بك، فيبدو أنه قد يكون لديك فكرة عن أحجامها المحتملة.إذا لم يكن الأمر كذلك، فأنا لا أرى ما هو البديل لديك حقًا، بدلاً من الإعلان عن حجم كبير جدًا لكل منها - كبير بما يكفي لاستيعاب معظم/أي قيم محتملة.

Answer 2

هذه هي الطريقة التي يقوم بها إطار العمل إذا كنت تستخدم مُنشئ SqlParameter الذي يأخذ فقط اسم المعلمة وقيمتها.قد يكون هناك عدم كفاءة طفيفة من جانب العميل، لكنني لم ألاحظ أبدًا اختلافًا في أداء الاستعلام.

Answer 3

نظرًا لأنك تستخدم CommandType = Text، فيجب أن تكون قادرًا على ضبط الحجم برمجيًا على الحجم الفعلي للمعلمة التي ترسلها.

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

Answer 4

يرجى نشر عينة من التعليمات البرمجية الخاصة بك.لا ينبغي عليك تعيين سمات الحجم على المعلمات الخاصة بك حتى تتمكن من الاتصال بـ .Prepare().

وبالمناسبة، ربما لا تحتاج حقًا إلى الاتصال بـ .Prepare()، خاصة إذا كنت تتصل بـ .Execute() بعد ذلك مباشرة.