إدارة العروض القابلة للتحديث وقيد WITH CHECK OPTION في MySQLMySQL Managing Updatable Views and WITH CHECK OPTION

لا يقتصر دور العروض في MySQL 8.4 على القراءة فقط؛ بل يمكن للعرض أن يكون قابلاً للتحديث (Updatable View) يقبل أوامر التعديل UPDATE وINSERT وDELETE ويترجمها مباشرةً إلى الجدول الفيزيائي الأصلي. والشرط الهندسي الجوهري لقابلية العرض للتحديث هو وجود تطابق أحادي مباشر (1-to-1 Row Mapping) بين كل صف يظهر في العرض وصف واحد محدد في الجدول الأساسي.

لكي يقبل العرض إدراج صفوف جديدة عبر INSERT، يشترط أيضاً:

• أن يتضمن العرض أسماء أعمدة جدول أساسي بسيطة دون تعبيرات حسابية مثل price * 1.15.
• أن يشمل العرض جميع أعمدة الجدول الأساسي المقيدة بـ NOT NULL والتي لا تملك قيمة افتراضية DEFAULT.
• يمكنك التحقق برمجياً من قابلية أي عرض للتحديث عبر استعلام العمود IS_UPDATABLE في جدول النظام information_schema.VIEWS.

متى يصبح العرض للقراءة فقط (Read-Only View) ويرفض أوامر التعديل؟ بمجرد أن يحتوي استعلام العرض على أي بنية SQL تدمج عدة صفوف في صف واحد أو تولّد قيماً مشتقة لا يمكن عكسها إلى صف أصلي محدد، يمنع MySQL التحديث ويُطلق الخطأ ERROR 1288 (HY000): The target table of the UPDATE is not updatable.

أبرز الموانع التي تجعل العرض غير قابل للتحديث:

• دوال التجميع والتلخيص: مثل SUM() وCOUNT() وAVG() وMIN() وMAX().
• عبارات التجميع والتكرار: وجود DISTINCT أو GROUP BY أو HAVING.
• عمليات المجموعات والنوافذ: وجود UNION أو UNION ALL أو دوال النوافذ OVER (...) أو الاستعلامات الفرعية في بند FROM.

تخيّل عرضاً باسم v_riyadh_branches يحمل الشرط WHERE city = 'Riyadh'. إذا لم تضع قيد حماية على هذا العرض، فبإمكان المستخدم تنفيذ UPDATE v_riyadh_branches SET city = 'Jeddah' WHERE branch_id = 10! سينفذ MySQL التعديل في الجدول الأصلي، لكن المفاجأة أن الصف رقم 10 سيختفي فوراً من العرض (مشكلة الصفوف المتلاشية Vanishing Rows)، بل ويمكن للمستخدم إدراج فرع في مدينة الدمام عبر عرض فروع الرياض!

لإغلاق هذه الثغرة المنطقية، نُلحق العبارة WITH CHECK OPTION في نهاية تعريف العرض؛ فتلزم محرك MySQL بفحص كل عملية INSERT أو UPDATE والتأكد من أن الصف الناتج بعد التعديل لا يزال يحقق شرط WHERE الخاص بالعرض، وإلا يُرفض التعديل بالخطأ ERROR 1369 (HY000): CHECK OPTION failed.

يسمح MySQL ببناء عرض فوق عرض آخر (Nested Views). وعند تداخل العروض تبرز أهمية تحديد نطاق الفحص في جملة WITH [CASCADED | LOCAL] CHECK OPTION:

• WITH CASCADED CHECK OPTION (الافتراضي): إذا كتبت WITH CHECK OPTION بدون كلمة إضافية، يعتمد MySQL الوضع المتسلسل CASCADED، فيتحقق من شرط WHERE في العرض الأعلى بالإضافة إلى شروط جميع العروض الأدنى التي يعتمد عليها حتى لو لم يُكتب فيها قيد فحص.
• WITH LOCAL CHECK OPTION: يفحص شرط WHERE الخاص بالعرض الحالي فقط، ولا يفحص العروض الأدنى إلا إذا كانت هي نفسها معرّفة بقيد فحص صريح.

كيف ينفذ محرك MySQL استعلام العرض داخلياً؟ يمكنك التحكم في طريقة المعالجة عبر تحديد الخوارزمية ALGORITHM = {UNDEFINED | MERGE | TEMPTABLE} عند إنشاء العرض:

• ALGORITHM = MERGE: يدمج MySQL نص استعلامك الخارجي مع استعلام العرض في جملة واحدة تنفذ مباشرةً على الجدول الأساسي (Query Rewriting). تتميز هذه الخوارزمية بأعلى سرعة وأقل استهلاك للذاكرة، وتسمح بتحديث البيانات عبر العرض.
• ALGORITHM = TEMPTABLE: ينفذ المحرك استعلام العرض أولاً ويخزن نتائجه في جدول مؤقت داخلي، ثم ينفذ استعلامك الخارجي فوق الجدول المؤقت. تُفرض هذه الخوارزمية تلقائياً عند وجود GROUP BY أو DISTINCT أو UNION، وتجعل العرض غير قابل للتحديث دائماً.
• ALGORITHM = UNDEFINED (الافتراضي): يترك القرار لمحسّن MySQL، والذي يفضّل MERGE دائماً متى ما سمحت بنية الاستعلام بذلك.

يلخّص الجدول المرجعي التالي قواعد قابلية العروض للتحديث في MySQL 8.4، ومقارنة خوارزميات المعالجة، وخيارات فحص الشروط: