يمكن لسكربتات Oracle SQL التي تنتجها وكلاء نماذج اللغات الكبيرة (LLM) أن تبدو مثالية على الورق، ومع ذلك قد تسبب كوارث في بيئة الإنتاج. ففي قاعدة كود برمجية قديمة تبلغ 2.3 مليون سطر، كان الوكيل المدعوم بالذكاء الاصطناعي يدرج بشكل متكرر معرفات غير موجودة – على سبيل المثال، استخدام POLICY_STATUS بدلاً من العمود الحقيقي STATUS_CD، أو الإشارة إلى جدول CUSTOMERS غير موجود بدلاً من CUSTOMER.
إن تشغيل السكربت لاكتشاف الخطأ المطبعي ليس خياراً متاحاً لجمل UPDATE أو DELETE. فتنفيذها على مجموعة بيانات تشبه بيئة الإنتاج يؤدي إلى حجز أقفال (locks)، واستهلاك أرقام التسلسل (sequence numbers)، ويمكن أن يؤدي إلى آثار جانبية متتالية. يحتاج المطورون إلى طريقة للتحقق من الأسماء والصيغة (syntax) دون المساس بأي بيانات. والإجابة، وهي بسيطة بشكل مفاجئ، تكمن في أمر Oracle EXPLAIN PLAN – بعد إعادة توظيفه كخطوة لفحص الأخطاء (linting).
كيف يعمل EXPLAIN PLAN كأداة تحقق سريعة
عندما تتلقى Oracle جملة برمجية، فإنها تقوم أولاً بتحليلها (Parsing). يتحقق التحليل من وجود كل جدول وعمود وصلاحية مستخدمة، ثم يبني خطة تنفيذ ويكتب تلك الخطة في جدول النظام. لا يقوم الأمر بتنفيذ الجملة أبداً: لا يتم تعديل أي صفوف، ولا يتم إطلاق أي مشغلات (triggers)، ولا يتم حجز أي أقفال (locks). وإذا واجه المحلل كائناً غير معروف، فإنه يطلق خطأً في غضون أجزاء من الثانية.
هذا السلوك يجعل EXPLAIN PLAN أداة مثالية للفحص المسبق لسكربتات SQL التي يولدها الذكاء الاصطناعي. حيث يتم الإبلاغ عن أي جدول أو عمود مفقود فوراً، مما يسمح لحلقة التوليد بتصحيح الخطأ قبل أن يرى البشر السكربت.
سير العمل الذي دمجته في خط أنابيب CI الخاص بي
- تقسيم السكربت الوارد إلى جمل فردية.
- تشغيل
EXPLAIN PLAN FOR <statement>مقابل مخطط تطوير (development schema). - جمع أي أخطاء تحليل ترجعها Oracle.
- تغذية الأخطاء مرة أخرى إلى الـ LLM لإعادة المحاولة.
من الناحية العملية، تنجح محاولة إعادة واحدة في معالجة غالبية أخطاء التسمية. يتعلم الذكاء الاصطناعي المخطط (schema) الصحيح ويعدل مخرجاته تلقائياً. لقد قمت أيضاً بتقييد الوكيل في وضع القراءة فقط: يمكنه إصدار جمل SELECT واستدعاءات EXPLAIN PLAN ، ولكن يتم حظر عمليات DDL و DML و COMMIT. تضمن هذه البيئة المعزولة (sandbox) بقاء قاعدة البيانات دون مساس بينما يستكشف الذكاء الاصطناعي هيكلها.
وبعيداً عن التحقق من الأسماء، تكشف الخطة الناتجة عن علامات تحذيرية واضحة تتعلق بالأداء. فإذا كانت الجملة ستؤدي إلى مسح كامل للجدول (full-table scan) في جدول ضخم، فإن الخطة تظهر ذلك قبل لمس أي صفوف، مما يمنح المطورين فرصة لاقتراح فهارس (indexes) أو إعادة كتابة الشرط (predicate).
حدود هذا النهج
- لا يتم التحقق من الصحة المنطقية. الجملة التي تشير إلى الأعمدة الصحيحة ولكن تطبق الفلتر الخاطئ ستجتاز فحص الأخطاء.
- كتل PL/SQL خارج النطاق. يتعامل المحلل فقط مع جمل SQL الفردية؛ أما الكود الإجرائي فيحتاج إلى مسار تحقق منفصل.
- يفتقر إلى التحقق على مستوى البيانات. لا يمكن لأداة الفحص إخبارك ما إذا كانت القيمة المكتوبة تتوافق مع نطاق العمود أو ما إذا كان مرجع المفتاح الأجنبي (foreign-key) موجوداً بالفعل.
- مخطط التطوير فقط. الأخطاء التي تظهر فقط في بيئة الإنتاج – على سبيل المثال، جدول موجود في بيئة التطوير ولكن تم تغيير اسمه في الإنتاج – تظل غير مرئية حتى وقت لاحق.
هذه الفجوات لا تقلل من فائدة هذه الطريقة؛ بل تحدد نطاق عملها فحسب. فبالنسبة لمعظم سكربتات DML التي يولدها الـ LLM، يكون نمط الفشل الأكثر شيوعاً هو خطأ مطبعي أو اسم كائن خاطئ، وهذا هو بالضبط ما يلتقطه EXPLAIN PLAN.
إمكانية النقل إلى محركات قواعد بيانات أخرى
ينطبق نفس المبدأ خارج Oracle. فجملة PREPARE في PostgreSQL أو EXPLAIN يمكنها تحليل الاستعلام دون تنفيذه. كما يوفر SQL Server الأمر SET PARSEONLY ON ، والذي يجبر المحرك على التحقق من الصيغة وأسماء الكائنات مع تخطي المعالجة الفعلية. أي نظام إدارة قواعد بيانات علاقي (RDBMS) يفصل بين عملية التحليل (parsing) والتنفيذ يمكن أن يصبح بوابة فحص (linting gate) خفيفة الوزن.
الخلاصة
إن تشغيل EXPLAIN PLAN (أو ما يعادله) على كل جملة SQL يتم إنشاؤها بواسطة الذكاء الاصطناعي يحول محلل قواعد البيانات إلى بوابة فحص (linting gate) منخفضة التكلفة وصفرية المخاطر. فهي تلتقط أكثر أخطاء التسمية والصيغة شيوعاً قبل تحريك أي بيانات، مما يحافظ على استقرار الأنظمة القديمة مع السماح للمطورين بجني ثمار زيادة الإنتاجية الناتجة عن البرمجة بمساعدة الـ LLM.