MySQL / الأسس العلائقية و SQL الدقيقة / الدرس 5

الإدراج والتحديث والحذف الآمن

تعامل مع تغييرات البيانات كحالات انتقال صريحة قابلة للمراجعة واحفظ بيانات التدريب الأصلية.

وقت القراءة التقريبي: 4 دقيقةتاريخ مراجعة المحتوى 2026-10-23

في هذه الصفحة

أهداف الدرس

اكتب تغييرات محددة النطاق وافحص الصفوف المتأثرة.
ميّز التراجع عن المعاملة والقيود والتحقق التطبيقي.

حدد الانتقال المقصود

استخدم بيانات المتجر الأصلية. ينبغي أن يحدد أمر التغيير كائن العمل وحالته الحالية المتوقعة وحالته الجديدة. تضيف INSERT حقائق وتغيّر UPDATE حقائق موجودة وتزيل DELETE حقائق. اعرض شرط التغيير بـ SELECT أولاً. تساعد المعاينة على التفكير لكنها لا تضمن التزامن، فقد تغيّر جلسة أخرى الصفوف قبل الكتابة.

سمّ كل عمود مدخل

تجعل قائمة الأعمدة الصريحة الإدراج واضحاً وتحميه من تغير ترتيب الأعمدة. قدم أرقام مراجع صحيحة لا أسماء متوقعة. تقلل الإدخالات المتعددة رحلات الاتصال لكن يجب تقرير هل تنجح كلها معاً. تظل قيود القاعدة ضرورية بعد فحص النموذج لأن الاستيراد والمهام الخلفية والطلبات المتزامنة قد تتجاوز النموذج.

sql التدرب على الإدراج دون إبقائه

START TRANSACTION;
INSERT INTO customers (id,name,email,city)
VALUES (4,'Sami','sami@example.test',NULL);
SELECT id,name FROM customers WHERE id=4;
ROLLBACK;

الناتج المتوقع

id | name
4 | Sami

يظهر داخل المعاملة الصف 4/Sami. وتزيله ROLLBACK فتعود البيانات إلى ثلاثة عملاء. يفترض المثال InnoDB وعدم وجود أمر يسبب تثبيتاً ضمنياً. ولا يعني ذلك إمكان التراجع عن كل عمليات الخادم.

اجعل الشرط جزءاً من الثابت

يتطلب خفض المخزون الآمن وضع هوية المنتج وكفاية المخزون في UPDATE واحدة. قد تؤدي قراءة المخزون ثم كتابة قيمة محسوبة لاحقاً إلى فقد شراء متزامن. يسمح التحديث الحسابي المشروط لـ InnoDB بتنسيق الكتّاب. ويجب فحص عدد الصفوف المتأثرة واعتبار الصفر شرطاً غير متحقق لا نجاحاً تلقائياً. وهذه قاعدة انتقالات الحالة التفاؤلية.

sql حجز دفترين مؤقتاً

START TRANSACTION;
UPDATE products SET stock=stock-2 WHERE id=1 AND stock>=2;
SELECT ROW_COUNT() AS changed_rows;
SELECT id,stock FROM products WHERE id=1;
ROLLBACK;

الناتج المتوقع

changed_rows
1
id | stock
1 | 18

بالمخزون الأصلي 20 يتغير صف واحد ويصبح مخزونه 18. تُفحص ROW_COUNT مباشرة بعد UPDATE قبل أن يستبدل أمر آخر التشخيص. وتعيد ROLLBACK المخزون إلى 20. ويجب كذلك التحقق من أن الكمية الواردة عدد صحيح موجب.

يتبع الحذف العلاقات

يفشل حذف العميل 1 ما دامت الطلبات تشير إليه، لأن بيانات التدريب لا تتضمن حذفاً متسلسلاً. يحمي ذلك التاريخ. وقد تعني عملية الحذف التجارية إخفاء المعلومات الشخصية مع حفظ السجلات المحاسبية اللازمة. تكون DELETE المشروطة قابلة للتراجع في InnoDB، أما TRUNCATE فهي DDL ذات سلوك تثبيت مختلف وليست بديلاً أسرع قابلاً للتراجع بالطريقة نفسها.

خطط للنجاح والفشل معاً

استخدم الأوضاع الصارمة لتفشل القيم غير الصحيحة بدلاً من تحولها إلى بدائل تبدو مقبولة. اقرأ رمز الخطأ واسم القيد وحالة المعاملة. لا يعني فشل أمر دائماً التراجع عن كل الأوامر السابقة؛ لذا ألغِ المعاملة صراحة عند فشل العملية التجارية. ولا تبن إشعارات الدفع وغيرها من الآثار الخارجية على افتراضات غير مثبتة، واستخدم صندوق إرسال أو أسلوب تسليم مناسب عند الحاجة.

الأخطاء الشائعة وإصلاحها

تغير مخزون جميع المنتجات.

لماذا يحدث؟: أُهمل شرط WHERE من UPDATE.
كيف تصلحه؟: تراجع عن المعاملة المفتوحة، وإن ثُبتت فاتبع خطة استعادة مدققة.
كيف تتجنب تكراره؟: عاين الشرط نفسه وتحقق من الحدود المتوقعة لعدد الصفوف.

ERROR 1451 (23000) عند حذف عميل.

لماذا يحدث؟: توجد طلبات أبناء ويمنع المفتاح الخارجي الحذف.
كيف تصلحه؟: اختر إجراءً مدروساً يحفظ التاريخ بدلاً من تعطيل الفحص.
كيف تتجنب تكراره؟: وثق قواعد دورة الحياة لكل علاقة قبل كتابة الحذف.

ERROR 3819 (HY000) بعد خفض المخزون.

لماذا يحدث؟: يخالف المخزون الجديد CHECK (stock >= 0).
كيف تصلحه؟: استخدم كمية مطلوبة موجبة وشرط كفاية المخزون.
كيف تتجنب تكراره؟: افرض الثابت بالقيد وشرط الكتابة معاً.

اختبر فهمك

1. احجز 21 دفتراً من المخزون الأصلي وتوقع التحديث المشروط.

اعرض الحل المشروح

لا تؤثر UPDATE products SET stock=stock-21 WHERE id=1 AND stock>=21 في أي صف لأن المخزون 20. لا ينشأ مخزون سالب ولا يلزم خطأ CHECK. يجب أن يبلغ التطبيق عن عدم كفاية المخزون وألا ينشئ حجزاً ناجحاً من هذه النتيجة.

2. عاين وتدرّب بأمان على تعليم الطلب 102 كمدفوع.