جمل INSERT وUPDATE وDELETE في SQL

لماذا يهم

جملة SELECT الخاطئة تعرض إجابة خاطئة، أما UPDATE أو DELETE الخاطئة فتُتلف البيانات. شرط واحد ناقص قد يلغي كل الطلبات في بيئة اختبار مشتركة، ومعظم برامج العميل تثبّت كل جملة فور نجاحها، فلا مجال للتراجع.

وبالانضباط تجعل الجمل نفسها الاختبار أسرع وأعمق: سكربت الزرع يمنح كل تشغيل بيانات البداية نفسها، وجملة UPDATE تنشئ اشتراكاً منتهياً في ثوانٍ، والجملة التي تخالف قاعدة عمداً تكشف هل تحمي قاعدة البيانات البيانات بنفسها.

INSERT: صف واحد أو عدة صفوف

تضيف INSERT صفوفاً جديدة: قائمة الأعمدة، ثم القيم بالترتيب نفسه. والعمود الذي تُغفله يأخذ قيمته الافتراضية (DEFAULT)، أو NULL إن لم تكن له قيمة افتراضية، والعمود NOT NULL الذي لا قيمة افتراضية له يُفشل الجملة. وحين تولّد قاعدة البيانات المفتاح، أغفل عموده وابحث عن الصف الجديد بقيمة اخترتها أنت، كالبريد الإلكتروني.

جملة INSERT متعددة الصفوف تضع عدة قوائم قيم بعد كلمة VALUES واحدة، ويقبلها PostgreSQL وMySQL وSQLite وSQL Server. والجملة ذرّية: إذا خالف صف واحد قاعدة، لا يُدرج أي صف (في MySQL مع محرك InnoDB الافتراضي).

• سمِّ الأعمدة: فالجملة التي تعتمد على ترتيب أعمدة الجدول تنكسر، أو تملأ أعمدة خاطئة، حين يتغيّر الجدول.
• النصوص والتواريخ بين علامتي اقتباس مفردتين، والأرقام وNULL بدونهما، وعلامة الاقتباس داخل النص تُكرَّر: 'O''Brien'.
• أدرج الآباء قبل الأبناء، لأن كل مفتاح أجنبي يتحقق من وجود الأب (ولا يفرض SQLite المفاتيح الأجنبية إلا بعد PRAGMA foreign_keys = ON).

-- Single-row INSERT: the column list, then the values in the same order
INSERT INTO customers (customer_id, email, full_name, created_at)
VALUES (9001, 'qa.sara@example.com', 'QA Sara Ahmed', '2026-09-01 09:00:00');
-- 1 row inserted

-- Multi-row INSERT: one statement, one list of values per row
INSERT INTO orders (order_id, customer_id, status, total_amount, created_at)
VALUES (9101, 9001, 'PENDING',  45.00, '2026-09-01 10:00:00'),
       (9102, 9001, 'PENDING', 120.00, '2026-09-01 10:05:00'),
       (9103, 9001, 'PAID',     80.00, '2026-09-02 09:30:00');
-- 3 rows inserted, or none: one bad row rejects the whole statement

-- A child row: order 9102 must already exist
INSERT INTO order_items (order_item_id, order_id, product_sku, quantity, unit_price)
VALUES (9201, 9102, 'SKU-100', 2, 60.00);

جرّبها: مولّد جمل SQL INSERT جرّبها: مولّد قوائم SQL VALUES

UPDATE وDELETE: اعدد الصفوف أولاً

تغيّر UPDATE أعمدة في صفوف موجودة، وتحذف DELETE صفوفاً كاملة. ويحدد شرط WHERE الصفوف التي تتأثر، وبدونه يتأثر كل صف. والشرط الخاطئ قليلاً أسوأ لأنه يبدو صحيحاً: نمط LIKE يطابق أكثر مما قصدت، و= NULL لا تطابق شيئاً، وOR تفلت من AND التي قبلها.

لذلك اعدد أولاً. شغّل شرط WHERE نفسه في SELECT يعرض الصفوف وفي SELECT COUNT(*)، وقارن العدد بما تتوقعه من المهمة. ثم استبدل الأسطر التي فوق WHERE وحدها لتصنع UPDATE أو DELETE، وقارن عدد الصفوف المتأثرة الذي يعرضه العميل بعددك. وإذا اختلفا فتوقف.

• يطبع psql الناتج UPDATE 2، ويطبع SQL Server الناتج (2 rows affected). أما MySQL فيعرض في جملة UPDATE الصفوف المطابقة والصفوف المتغيّرة، ولا يحسب افتراضياً ضمن المتأثرة إلا الصفوف التي تغيّرت قيمتها فعلاً، فقارن عدد الصفوف المطابقة بعددك.
• قبل حذف صف أب، اعدد أبناءه: فالمفتاح الأجنبي يرفض DELETE، أو يحذف الأبناء معه إن عُرِّف مع ON DELETE CASCADE، والعدد المُبلَّغ لا يشمل إلا الجدول الذي سمّيته.

-- 1. The WHERE you intend, as a SELECT: look at the rows, then count them
SELECT order_id, status
FROM orders
WHERE customer_id = 9001 AND status = 'PENDING';
-- 9101  PENDING
-- 9102  PENDING

SELECT COUNT(*)
FROM orders
WHERE customer_id = 9001 AND status = 'PENDING';
-- 2, as expected: the test customer has two pending orders

-- 2. The same WHERE, only the lines above it changed
UPDATE orders
SET status = 'CANCELLED'
WHERE customer_id = 9001 AND status = 'PENDING';
-- rows affected: 2, equal to the count

-- 3. DELETE: count the children before removing the parent
SELECT COUNT(*) FROM order_items WHERE order_id = 9102;   -- 1
DELETE FROM orders WHERE order_id = 9102;
-- rejected by the foreign key from order_items; with ON DELETE CASCADE
-- it would succeed, report 1 row and remove the item line as well

جرّبها: مدقّق استعلامات SQL جرّبها: مولّد عبارات SQL IN

تدرّب داخل معاملة: BEGIN … ROLLBACK

تبدأ معظم برامج العميل في وضع التثبيت التلقائي (Autocommit)، وفيه تُثبَّت كل جملة فور نجاحها؛ فتحقّق من هذا الإعداد في برنامجك. أما BEGIN فتفتح معاملة (Transaction)، أي مجموعة جمل تُبقيها قاعدة البيانات أو تتراجع عنها بوصفها وحدة واحدة: ترى جلستك التغييرات التي تليها، لكن الجلسات الأخرى، ومنها التطبيق، لا تراها حتى تجعلها COMMIT دائمة، وROLLBACK تُلغيها كلها. وهذا ما يحدث في مستوى العزل (Isolation Level) الافتراضي، وهو الإعداد الذي يحدد ما تراه الجلسات الأخرى من معاملة لم تُثبَّت بعد؛ ويشرح دليل اختبار المعاملات وترحيلات قواعد البيانات هذه المستويات. ويكتب SQL Server الأمر BEGIN TRANSACTION، ويقبل MySQL أيضاً START TRANSACTION.

الروتين: اعدد بـSELECT، ثم BEGIN، ثم نفّذ التغيير، وقارن الصفوف المتأثرة بالعدد، وافحص النتيجة بـSELECT داخل المعاملة، ثم ROLLBACK إن اختلف شيء أو كنت تتدرّب فقط. ولا تنفّذ COMMIT إلا حين تتطابق كل الأرقام ويكون التغيير مقصوداً أن يبقى.

لا تفعل ذلك إلا على قاعدة بيانات اختبار: قاعدتك المؤقتة الخاصة، أو بيئة مشتركة وافق مالكها، وهو عادةً قائد الجودة أو الفريق الذي يديرها. أما تغييرات بيانات الإنتاج فتمرّ بإجراءات التغيير المعتمدة في الفريق، لا بعميل SQL لدى المختبِر.

• لا يرى التطبيق الصفوف غير المثبَّتة: لتختبر شاشة بالبيانات الجديدة يجب أن تنفّذ COMMIT، وأن تخطط لاستعادة البيانات.
• المعاملة المفتوحة تقفل الصفوف التي غيّرتها وتجعل من يكتب فيها ينتظر: أنهِها سريعاً.
• في PostgreSQL يُجهض أي خطأ المعاملة، فتفشل كل جملة لاحقة حتى ROLLBACK.
• لا يتراجع ROLLBACK عن كل شيء: لا يعيد PostgreSQL وMySQL وSQL Server قيم المفاتيح المولَّدة المستهلكة، وفي MySQL تثبّت TRUNCATE أو ALTER TABLE المعاملة المفتوحة ضمنياً.

زرع بيانات الاختبار وتعمّد مخالفة القيود

زرع البيانات (Seeding) هو تحميل بيانات معروفة قبل الاختبار ليبدأ من حالة اخترتها. احفظ جمل INSERT في سكربت زرع بجوار الاختبارات، وعلّم كل صف ببادئة QA- أو بريد على النطاق example.com أو نطاق مفاتيح متفق عليه، ليحذف السكربت صفوفه أولاً، الأبناء قبل الآباء.

جمل SQL تلتف حول التطبيق: الصف المكتوب يدوياً يتخطى التحقق من صحة المدخلات وسجل التدقيق والذاكرة المؤقتة. وهكذا تصل إلى حالات بسرعة، مثل طلب أُنشئ قبل ⁦31⁩ يوماً، لكنك قد تصنع بيانات لا يمكن للمنتج أن ينتجها، فدوّن في حالة الاختبار أي البيانات جاءت من SQL.

وتختبر جمل DML أيضاً قواعد قاعدة البيانات نفسها، أي قيودها (Constraints): NOT NULL والمفتاح الأساسي وUNIQUE والمفاتيح الأجنبية وCHECK، وهو شرط يجب أن يحققه كل صف، مثل CHECK (quantity > 0). اكتب جملة تخالف قاعدة واحدة بالضبط وتوقّع النتيجة: رفض بخطأ قيد، ودون أن تتغيّر أي بيانات. والقيود تحرس UPDATE وDELETE كما تحرس INSERT. أنهِ كل محاولة بـROLLBACK، فإن كانت القاعدة غائبة لا تبقى البيانات الفاسدة: والجملة التي تنجح هي الملاحظة نفسها.

-- One broken rule per transaction, on your own test database.
-- If a rule is missing, ROLLBACK still removes the bad data.

BEGIN;
UPDATE order_items SET quantity = 0 WHERE order_item_id = 9201;
-- expected: rejected by CHECK (quantity > 0); quantity stays 2
ROLLBACK;

BEGIN;
DELETE FROM customers WHERE customer_id = 9001;
-- expected: rejected by the foreign key from orders (9101 to 9103)
ROLLBACK;

BEGIN;
INSERT INTO customers (customer_id, email, full_name, created_at)
VALUES (9002, 'qa.sara@example.com', 'QA Copy', '2026-09-01 09:00:00');
-- expected: rejected by UNIQUE (email); still one row with this email
ROLLBACK;

جرّبها: مولّد مجموعات بيانات SQL جرّبها: محوّل CSV إلى SQL

مثال تطبيقي: التدرّب على سكربت تصحيح بيانات

تحتوي تذكرة على سكربت تصحيح بيانات سينفّذه مطوّر في الإنتاج: إلغاء الطلبات المتروكة، أي الطلبات التي أُنشئت قبل ⁦1⁩ أغسطس وما زالت PENDING ولا دفعة مُحصَّلة لها. وتقول التذكرة إنه يلغي ثلاثة: ⁦1201⁩ و⁦1202⁩ و⁦1205⁩. وتحوي بيئة Staging نسخة حديثة مُقنَّعة من بيانات الإنتاج، ويوافق مالكها على أن تتدرّب على السكربت هناك، بشرط أن تبقى البيئة كما كانت.

يعيد العدّ المسبق بشرط WHERE الخاص بالسكربت العدد ⁦4⁩. وعرض هذه الصفوف مع دفعاتها يكشف السبب: الطلب ⁦1188⁩ حالته PENDING لكن له دفعة CAPTURED، والسكربت لا يشترط شيئاً على الدفعات. لم يتغيّر شيء بعد، فتتوقف وتُبلغ.

• الملاحظة الأولى: السكربت سيلغي طلباً مدفوعاً. يضيف المطوّر NOT EXISTS (SELECT 1 FROM payments …)، وهو استعلام فرعي يستبعد الطلبات التي لها دفعة مُحصَّلة، فيصبح العدد ⁦3⁩. واختير NOT EXISTS لا NOT IN، لأن NOT IN لا يطابق شيئاً متى أعاد استعلامه الفرعي قيمة NULL.
• الملاحظة الثانية: الطلب ⁦1188⁩ مدفوع لكنه ما زال PENDING. أبلغ عنه في بلاغ مستقل، فهو يشير إلى عيب محتمل في مسار الدفع.
• التدرّب: ⁦3⁩ صفوف متأثرة، مساوية للعدد؛ وداخل المعاملة صارت ⁦1201⁩ و⁦1202⁩ و⁦1205⁩ بحالة CANCELLED وبقي صف المراقبة ⁦1188⁩ بحالة PENDING؛ وبعد ROLLBACK عادت الأربعة إلى PENDING.
• تدخل الاستعلامات والأعداد وناتج SELECT الأخير في التذكرة، فيبدأ تشغيل الإنتاج بالعدّ نفسه ولا يمضي إلا إذا بقي مطابقاً.

-- The developer's data-fix script, to run in production later:
--   UPDATE orders SET status = 'CANCELLED'
--   WHERE status = 'PENDING' AND created_at < '2026-08-01';
-- Ticket: "cancels 3 abandoned orders: 1201, 1202, 1205"

-- 1. Count first with the script's own WHERE
SELECT COUNT(*) FROM orders
WHERE status = 'PENDING' AND created_at < '2026-08-01';
-- 4, the ticket says 3: stop and list the rows with their payments
SELECT o.order_id, p.status AS payment
FROM orders o
LEFT JOIN payments p ON p.order_id = o.order_id
WHERE o.status = 'PENDING' AND o.created_at < '2026-08-01'
ORDER BY o.order_id;
-- 1188  CAPTURED    <- paid, yet still PENDING
-- 1201  NULL
-- 1202  NULL
-- 1205  NULL

-- 2. The developer's fixed WHERE: count again
SELECT COUNT(*) FROM orders
WHERE status = 'PENDING' AND created_at < '2026-08-01'
  AND NOT EXISTS (SELECT 1 FROM payments p
                  WHERE p.order_id = orders.order_id AND p.status = 'CAPTURED');
-- 3

-- 3. Rehearse on staging with the owner's agreement, then undo
BEGIN;
UPDATE orders SET status = 'CANCELLED'
WHERE status = 'PENDING' AND created_at < '2026-08-01'
  AND NOT EXISTS (SELECT 1 FROM payments p
                  WHERE p.order_id = orders.order_id AND p.status = 'CAPTURED');
-- rows affected: 3, equal to the count

SELECT order_id, status FROM orders
WHERE order_id IN (1188, 1201, 1202, 1205);
-- 1188 PENDING, 1201 CANCELLED, 1202 CANCELLED, 1205 CANCELLED

ROLLBACK;
-- the same SELECT now shows all four orders PENDING again

أسئلة شائعة

المراجع

• ISO/IEC 9075-1:2023 — Information technology — Database languages SQL — Part 1: Framework (SQL/Framework)ISO/IEC · 2023الجزء الإطاري من معيار SQL الدولي، الذي تنفّذه لهجات PostgreSQL وMySQL وSQLite وغيرها بدرجات متفاوتة.
• Transactions — PostgreSQL DocumentationPostgreSQL Global Development Groupما المعاملة: عدة خطوات تُطبَّق كلها أو لا شيء عبر BEGIN وCOMMIT وROLLBACK، ولا يراها الآخرون قبل التثبيت.
• SQL As Understood By SQLiteSQLiteقواعد SQL التي يقبلها SQLite، عبارة تلو الأخرى، مع مخططات نحوية.
• Constraints — PostgreSQL DocumentationPostgreSQL Global Development Groupقيود التحقق وعدم القيمة الفارغة والتفرّد والمفتاح الأساسي والمفتاح الأجنبي والإقصاء — القواعد التي تفرضها قاعدة البيانات ويتحقق منها المختبِر.