التحقق من التجاوزات الحسابية في الأعمدة المحسوبة؟

Question

في تطبيقنا، سنسمح للمستخدمين بكتابة التعبيرات الحسابية (+ - * /) باستخدام أعمدة قاعدة بيانات أخرى للأرقام، والتي سيتم بعد ذلك تحليلها بواسطة التطبيق وكتابتها في قاعدة البيانات كعمود محسوب.

ومع ذلك، هناك مشكلات تنشأ عند السماح للمستخدمين بإنشاء تعبيرات قد تسبب استثناءات عند قيامك بذلك select * الجدول، مثل القسمة على صفر، والتجاوز الحسابي، وغيرها من الاحتمالات التي لم أصادفها بعد (على الرغم من أنني يفكر هذا كل منهم).

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

بالنسبة للقسمة على صفر، الحل واضح جدًا:

add [Col] as case {divisor} when 0 then N'DIVIDE-BY-ZERO' else {expression} end

سؤالي هو ماذا يمكنني أن أفعل للتجاوز الحسابي؟لن يمثل عرض البيانات غير المنتظمة أو الخاطئة بشكل واضح في العمود مشكلة، ولكن طرح الاستثناءات قد يمثل مشكلة.

Answer 1

أكره أن أراك تقبل إجابة لا تقربك حقًا من هدفك.

كإجابة منفصلة قد تساعدك قليلاً، أنت يستطيع جعل الأعمدة المحسوبة تستدعي UDF العددي (الحتمي).

انظر على سبيل المثال، هنا

لذا، إذا كنت ستقوم بإنشاء عمود محسوب، فاجعله يمرر الأعمدة إلى UDF الذي تم إنشاؤه (أو عدة UDFs) وقم بالعمل هناك.في UDF العددي، يمكن أن يكون لديك الكثير من التعليمات البرمجية لحل المشكلات ولكنك لا تزال غير قادر على استخدامها TRY/CATCH.ما يمكنك فعله في UDF العددي الخاص بك هو التقاط الحالات وإرجاع الإجابات المناسبة (ربما تنبثق القيم الخالية).

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

Answer 2

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

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

إذا كنت تقوم بالفعل بتحليل التعبير، فسوف أقوم بتجميع هذا من جانب العميل أيضًا، وأتعامل مع الخطأ على أساس صف تلو الآخر.

اصطياد الاستثناء باستخدام حاول/قبض هو سيناريو كل شيء أو لا شيء، وليس على أساس صف تلو الآخر.

Answer 3

ماذا عن اصطياد الاستثناءات؟يبدو من الصعب محاولة اكتشاف جميع الأسباب المحتملة للتجاوزات الحسابية، ناهيك عن الاستثناءات بشكل عام.

في الاستثناءات، يمكنك إرجاع مجموعة نتائج غير منطقية متوافقة مع المجموعة الأصلية المحددة من قبل المستخدم:

begin try
    select exp(999)
end try
begin catch
    select 1
end catch 

Answer 4

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

إذا لم يكن الأداء مهمًا، فاستخدم دالة ذات قيمة عددية.