يفترض تقرير ERP عرض الموردين غير الموجودين في قائمة استبعاد. يعمل في الاختبار ثم يعود بلا نتائج بعد استيراد ملف جديد. قد لا يكون السبب نقص البيانات؛ وجود قيمة NULL داخل نتيجة الاستعلام الفرعي يغير معنى NOT IN. افحص قواعد المقارنة قبل تعديل الواجهة أو إعادة استيراد السجلات.
اكتب نتيجة متوقعة لثلاث حالات
توضح وثائق PostgreSQL 17 للاستعلامات الفرعية أن المقارنة بـNOT IN قد تعيد null بدل true عندما لا توجد قيمة مساوية وتحتوي الجهة اليمنى على null. أما EXISTS فيختبر وجود صفوف. هذه دلالات مختلفة، وليست وعدًا بأن تغيير اسم العامل وحده يصلح التقرير.
| تعبير تجريبي | النتيجة المنطقية |
|---|---|
| 3 NOT IN (1, 2) | true |
| 3 NOT IN (1, NULL) | NULL، وليست true |
| 1 NOT IN (1, NULL) | false |
نفذ الأمثلة في قاعدة اختبار. مرشح WHERE يحتفظ بالصفوف التي تحقق true؛ النتيجة المجهولة لا تُعامل كقبول. لذلك يمكن لقيمة مجهولة في قائمة الاستبعاد أن تمنع صفًا كنت تتوقع ظهوره، رغم عدم وجود رقم مطابق له.
حدد معنى القيمة المجهولة في العمل
هل NULL خطأ استيراد يجب مراجعته، أم مورد لم يحصل على معرف خارجي بعد؟ لا تحولها إلى صفر أو رقم وهمي لإجبار المقارنة على العمل. اجعل هناك قائمة استثناءات ومطلبًا واضحًا لكيفية ظهور السجلات غير المكتملة في التقارير.
راجع البديل وحدود الشركة
يمكن تصميم NOT EXISTS مع شرط ربط مناسب، لكن افحص أيضًا المعرف الفارغ في الصف الخارجي؛ المساواة مع NULL لا تتصرف كهوية معلومة. اكتب حالات المورد المجهول والقائمة الخالية والقيم المكررة قبل اعتماد البديل. إذا كانت الأرقام تتكرر بين الشركات، أدخل نطاق الشركة في شرط الربط الصحيح.
في مثال افتراضي، يتطابق كود مورد في شركتين لكن الاستبعاد يخص واحدة فقط. معالجة NULL لن تحل غياب قيد الشركة. طابق كل نتيجة بمعرف السجل والشركة، ولا تكتف بعدد إجمالي يبدو معقولًا.
ثبت اختبارًا يمنع رجوع الخلل
سلّم عينة بيانات صغيرة وناتجها المتوقع ضمن تقارير ERP والفحص التقني. قارن صحة النتائج أولًا ثم الأداء في البيئة المناسبة. المطلوب تفسير واضح لمن يظهر ولماذا، دون إخفاء بيانات مجهولة أو تغيير سياسة التقرير ضمن إصلاح تقني غير معلن.
