يمكن لقاعدة CRM أن ترفض طلبًا يشير إلى عميل غير موجود، ومع ذلك تتباطأ عملية مراجعة طلبات العميل عند حذفه. نجاح قيد العلاقة لا يخبرك وحده كيف سيبحث PostgreSQL داخل الجدول التابع. قبل اقتراح زيادة موارد السيرفر، ارسم العلاقة وحدد الأعمدة التي يجري البحث فيها فعلًا.
حدد الطرف المرجعي والطرف التابع
توضح وثائق PostgreSQL 17 للقيود أن الأعمدة المشار إليها تحتاج مفتاحًا أساسيًا أو قيدًا فريدًا أو فهرسًا فريدًا مناسبًا. لكن إعلان المفتاح الأجنبي لا ينشئ تلقائيًا فهرسًا على أعمدة الجدول الذي يحمل الإشارة. فحص الصفوف التابعة عند حذف المرجع أو تحديث مفتاحه قد يستفيد من فهرستها؛ القرار يعتمد على الاستخدام.
في نموذج افتراضي، يحمل جدول orders الحقل customer_id الذي يشير إلى customers.id. وجود فهرس على customers.id لا يثبت وجود فهرس مناسب للبحث عن طلبات عميل داخل orders. ولا تجعل تشابه أسماء الأعمدة بديلًا عن قراءة تعريف القيد والفهارس الفعلية.
جهز ورقة مراجعة لكل علاقة
| ما تسجله | لماذا يهم؟ |
|---|---|
| الأعمدة التابعة وترتيبها | تحديد ما يبحث فيه الاستعلام |
| الفهارس القائمة وترتيب أعمدتها | تجنب إضافة نسخة زائدة من فهرس مناسب |
| سياسة الحذف والتحديث | فصل الأداء عن نتيجة الحذف المسموحة |
| حجم البيانات وتوزيعها | فهم اختلاف العينة الصغيرة عن العمل الفعلي |
اختبر البحث قبل تجربة الحذف
أنشئ بيانات مصطنعة بحجم وتوزيع مناسبين في بيئة منفصلة، ثم راجع خطة البحث عن الصفوف التابعة. قارن الخطة والقراءات ضمن الشروط نفسها قبل اقتراح فهرس وبعده. الخطة التي تختار مسحًا تسلسليًا لجدول صغير ليست تلقائيًا خطأ؛ ولا ننسب هنا زمن تسريع إلى مشروع لم يُقَس.
إذا احتاج التحقق تجربة عملية حذف، فراجع أثر القيود والمشغلات والصلاحيات أولًا ونفذها في قاعدة تجريبية قابلة لإعادة البناء. لا تستخدم حذف عميل حقيقي كاختبار أداء، ولا تغير CASCADE لتجاوز انتظار غير مفهوم.
راجع الكلفة والنتيجة معًا
الفهرس المقترح يحتاج مساحة وصيانة عند الكتابة. سلّم تعريف العلاقة وخطة الاستعلام وسبب الاختيار ضمن تطوير CRM والمراجعة التقنية. معيار القبول أن تظل سلامة البيانات وسياسة الحذف صحيحتين، وأن يستند قرار الفهرسة إلى مسار عمل مقاس، مع خطة نشر مستقلة يراجعها المسؤول.
