يعرض تقرير ERP إجماليًا ثم قائمة تفاصيل لا يبدو أنها تفسره. قبل اتهام الجمع أو الواجهة، اسأل هل قرأ الاستعلامان البيانات في اللحظة المنطقية نفسها. تحديث ملتزم بين قراءة الملخص وقراءة التفاصيل قد يجعل النتيجتين تعكسان حالتين مختلفتين، حتى لو كان كل استعلام صحيحًا منفردًا.
معاملة واحدة لا تعني دائمًا لقطة واحدة
تشرح وثائق PostgreSQL 18 لعزل المعاملات أن Read Committed، وهو المستوى الافتراضي، يأخذ لقطة لكل أمر. لذلك قد ترى عبارتا SELECT متتاليتان تغيرات التزمت بينهما داخل المعاملة نفسها. أما Repeatable Read فيربط القراءة بلقطة أول أمر غير مخصص للتحكم في المعاملة، مع رؤية تغييرات المعاملة نفسها إن وجدت.
المقصود هنا تقرير قراءة محدود، وليس منع بيع آخر قطعة أو حماية تعديل متزامن. تلك قواعد كتابة مختلفة؛ ثبات لقطة التقرير لا يثبت صحة كل قرارات الأعمال المتزامنة، ولا يغني عن تفويض نطاق بياناته.
جرب نافذة التغيير بجلستين
- جهز بيانات أوامر مصطنعة في قاعدة تجريبية وحدد حالة تؤثر في الملخص والتفاصيل.
- ابدأ جلسة التقرير واقرأ الملخص ضمن العزل المراد اختباره.
- من جلسة ثانية، غيّر حالة أمر تجريبي ثم نفذ commit.
- ارجع إلى جلسة التقرير واقرأ التفاصيل ثم أنهِ المعاملة.
كرر السيناريو بالمدخلات نفسها لكل مستوى، وسجل أي نسخة من البيانات يتوقع أن يراها كل استعلام. لا تقارن رقمين من تجارب عشوائية لا تعرف متى التزم التغيير بينهما.
ضع الاستعلامات تحت نطاق واحد فعلًا
إذا قرأ الملخص من اتصال والتفاصيل من آخر، أو من مخزن مؤقت مختلف، فلا تفترض أن ضبط معاملة في موضع واحد يوحد الصورة كلها. راجع اتصال قاعدة البيانات ومسار الكاش وأي مصدر خارجي مشارك في التقرير. كذلك يجب أن تتفق مرشحات الجهة والتاريخ والحالة قبل تفسير أي اختلاف بالعزل.
احصر التغيير في التقرير المقصود
في تطوير ERP لا ترفع عزل كل التطبيق كحل سريع. صمم معاملة قراءة قصيرة، وراجع أثرها وكلفة التقرير ضمن المراجعة التقنية. لا تتركها مفتوحة أثناء تفاعل المستخدم أو تحميل ملف طويل دون خطة.
وإذا تحول المسار إلى كتابة، فراجع احتمال فشل serialization وسياسة إعادة المعاملة كاملة؛ لا تنقل استنتاجات القراءة إليها بلا اختبار. دليل القبول لهذا التقرير هو اتساق الملخص والتفاصيل ضمن اللقطة والمرشحات المعلنة، مع انتهاء المعاملة ومعالجة الفشل بوضوح، لا ادعاء اتساق شامل للنظام.
