SQL للمختبِرين

قبل أن تشغّل أي شيء: الممارسة الآمنة

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

• استخدم حساباً للقراءة فقط (Read-only) للتحقق. إن كان حسابك يستطيع الكتابة، تتحول زلّة واحدة إلى توقف أو فقدان لبيانات اختبار الفريق كله.
• لا تشغّل UPDATE أو DELETE على بيئة مشتركة (Staging أو UAT أو قاعدة اختبار مشتركة) دون موافقة مالكها. أعلن ذلك، واحفظ العبارة بنصها في التذكرة.
• قبل أي UPDATE أو DELETE، شغّل عبارة WHERE نفسها مع SELECT COUNT(*) وتحقق من العدد. ثم نفّذ التغيير داخل معاملة وقارن عدد الصفوف المتأثرة قبل COMMIT.
• أثناء استكشاف جدول كبير، أضف LIMIT (أو ما يعادله في لهجتك) ورشّح على أعمدة مفهرسة مثل المفتاح الأساسي أو نطاق تواريخ.
• لا تتصفح البيانات الشخصية في الإنتاج للتسهيل. وإن كان الوصول إلى الإنتاج جزءاً من دورك، فالتزم بقواعد الوصول والتسجيل المصاحبة له.

-- On your own test database only
BEGIN;

SELECT COUNT(*) AS will_change
FROM orders
WHERE status = 'PENDING' AND created_at < '2026-01-01';
-- expect: 3

UPDATE orders
SET status = 'CANCELLED'
WHERE status = 'PENDING' AND created_at < '2026-01-01';
-- the client reports rows affected: must also be 3

ROLLBACK;  -- COMMIT only when every number matches

المخطط المستخدم في الأمثلة

تستخدم الأمثلة أربعة جداول. العميل يضع طلبات؛ ولكل طلب سطر صنف واحد أو أكثر وصفر دفعات أو أكثر. يصرّح المخطط بالمفاتيح الأساسية وبريد فريد وأعمدة NOT NULL وقيود CHECK لقيم الحالة والمبالغ ومفاتيح أجنبية. ويستخدم صيغ القيود على مستوى الجدول التي يقبلها PostgreSQL وMySQL 8 وSQLite جميعاً؛ وتذكّر أن MySQL لا يفرض CHECK إلا من 8.0.16، وأن SQLite لا يفرض المفاتيح الأجنبية إلا مع PRAGMA foreign_keys = ON.

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

CREATE TABLE customers (
  customer_id  INTEGER       NOT NULL,
  email        VARCHAR(254)  NOT NULL,
  full_name    VARCHAR(200)  NOT NULL,
  created_at   TIMESTAMP     NOT NULL,
  CONSTRAINT pk_customers PRIMARY KEY (customer_id),
  CONSTRAINT uq_customers_email UNIQUE (email)
);

CREATE TABLE orders (
  order_id     INTEGER       NOT NULL,
  customer_id  INTEGER       NOT NULL,
  status       VARCHAR(20)   NOT NULL,
  total_amount NUMERIC(12,2) NOT NULL,
  created_at   TIMESTAMP     NOT NULL,
  CONSTRAINT pk_orders PRIMARY KEY (order_id),
  CONSTRAINT fk_orders_customer FOREIGN KEY (customer_id) REFERENCES customers (customer_id),
  CONSTRAINT ck_orders_status CHECK (status IN ('PENDING', 'PAID', 'SHIPPED', 'CANCELLED')),
  CONSTRAINT ck_orders_total CHECK (total_amount >= 0)
);

CREATE TABLE order_items (
  order_item_id INTEGER       NOT NULL,
  order_id      INTEGER       NOT NULL,
  product_sku   VARCHAR(40)   NOT NULL,
  quantity      INTEGER       NOT NULL,
  unit_price    NUMERIC(12,2) NOT NULL,
  CONSTRAINT pk_order_items PRIMARY KEY (order_item_id),
  CONSTRAINT fk_items_order FOREIGN KEY (order_id) REFERENCES orders (order_id),
  CONSTRAINT ck_items_quantity CHECK (quantity > 0),
  CONSTRAINT ck_items_price CHECK (unit_price >= 0)
);

CREATE TABLE payments (
  payment_id   INTEGER       NOT NULL,
  order_id     INTEGER       NOT NULL,
  amount       NUMERIC(12,2) NOT NULL,
  status       VARCHAR(20)   NOT NULL,
  paid_at      TIMESTAMP     NULL,
  CONSTRAINT pk_payments PRIMARY KEY (payment_id),
  CONSTRAINT fk_payments_order FOREIGN KEY (order_id) REFERENCES orders (order_id),
  CONSTRAINT ck_payments_status CHECK (status IN ('CAPTURED', 'FAILED', 'REFUNDED'))
);

-- Business rules the checks below verify:
-- R1 orders.total_amount = SUM(quantity * unit_price) of its items (no tax or discount here)
-- R2 a PAID or SHIPPED order has CAPTURED payments that add up to total_amount
-- R3 a CAPTURED payment has paid_at, and paid_at is not earlier than the order's created_at

جرّبها: مولّد مجموعات بيانات SQL جرّبها: مولّد جمل SQL INSERT

تحقق من تغيير واحد: ابحث بالمفتاح

بعد إجراء في الواجهة أو API، اعثر على الصفوف المتأثرة بالمفتاح الذي أعطاك إياه التطبيق — معرّف الطلب في استجابة API أو المعرّف في رابط الصفحة — لا بـ«آخر صف»، فقد يكون مختبِر آخر أنشأ صفاً قبلك بثانية. اختر أعمدة صريحة لا SELECT *، ليُظهر الناتج الحقول التي تفحصها بالضبط ولا ينكسر حين يُضاف عمود.

افحص الأب والأبناء معاً. بعد الإنشاء يجب أن توجد أسطر الأصناف بالكميات والأسعار الصحيحة؛ وبعد الحذف يصبح السؤال ما الذي بقي، ويجيب عنه صف واحد بثلاثة أعداد في استعلام واحد.

-- The API returned order_id 1042
SELECT o.order_id, o.status, o.total_amount, o.created_at, c.email
FROM orders o
JOIN customers c ON c.customer_id = o.customer_id
WHERE o.order_id = 1042;

SELECT order_item_id, product_sku, quantity, unit_price
FROM order_items
WHERE order_id = 1042
ORDER BY order_item_id;

-- After a hard delete of order 1042: nothing left behind anywhere
SELECT
  (SELECT COUNT(*) FROM orders      WHERE order_id = 1042) AS orders_left,
  (SELECT COUNT(*) FROM order_items WHERE order_id = 1042) AS items_left,
  (SELECT COUNT(*) FROM payments    WHERE order_id = 1042) AS payments_left;

مطابقة الأعداد والمجاميع

المطابقة (Reconciliation) تقارن رقمين يجب أن يتفقا. داخل قاعدة واحدة يكون ذلك رأس الطلب مقابل أسطره (R1) أو الطلبات مقابل الدفعات (R2)؛ وبين الأنظمة يكون العدد والمجموع نفسيهما محسوبين في مكانين — قاعدة الطلبات وخدمة الفوترة، أو القاعدة وتقرير مالي. يعيد GROUP BY مع HAVING المجموعات المختلفة فقط، فالنتيجة الفارغة نجاح.

تفصيلتان تمنعان الإنذارات الكاذبة. قارن المبالغ في أنواع عشرية دقيقة مثل NUMERIC أو DECIMAL فقط؛ وإن كانت المبالغ مخزّنة كفاصلة عائمة فتلك ملاحظة بحد ذاتها. واستخدم COALESCE حين قد لا يكون لأحد الطرفين صفوف، لأن SUM على صفر صفوف يعطي NULL، والمقارنة مع NULL لا تكون صحيحة أبداً، فيختفي طلب لا دفعات له إطلاقاً.

-- R1: order header total vs the sum of its lines
SELECT o.order_id, o.total_amount,
       SUM(oi.quantity * oi.unit_price) AS lines_total
FROM orders o
JOIN order_items oi ON oi.order_id = o.order_id
GROUP BY o.order_id, o.total_amount
HAVING o.total_amount <> SUM(oi.quantity * oi.unit_price);

-- R2: paid orders vs captured payments
SELECT o.order_id, o.total_amount,
       COALESCE(SUM(p.amount), 0) AS captured
FROM orders o
LEFT JOIN payments p
  ON p.order_id = o.order_id AND p.status = 'CAPTURED'
WHERE o.status IN ('PAID', 'SHIPPED')
GROUP BY o.order_id, o.total_amount
HAVING COALESCE(SUM(p.amount), 0) <> o.total_amount;

-- Count and sum per status for one month, to compare with a report or another service
SELECT status, COUNT(*) AS order_count, SUM(total_amount) AS amount_sum
FROM orders
WHERE created_at >= '2026-09-01' AND created_at < '2026-10-01'
GROUP BY status
ORDER BY status;

جرّبها: منسّق SQL

كشف الصفوف اليتيمة بـ LEFT JOIN … IS NULL

الصف اليتيم (Orphan) صف فرعي لا وجود لأبيه. يحتفظ LEFT JOIN بكل صف فرعي ويملأ أعمدة الأب بـ NULL حين لا يطابقه أب، فالترشيح على أن مفتاح الأب IS NULL يسرد الأيتام بالضبط. والشكل نفسه في الاتجاه المعاكس يجد آباء بلا الأبناء الذين يجب أن يكونوا لهم، مثل طلب بلا أصناف.

مع مفاتيح أجنبية مصرّح بها ومفروضة لا يمكن إنشاء أيتام — لكنهم يظهرون حين تُعطَّل القيود لتحميل جماعي، أو حين يعمل SQLite دون إعداد المفاتيح الأجنبية، أو حين تمتد العلاقة بين قاعدتي خدمتين، أو حين لم يُنشأ القيد قط. تجنّب NOT IN مع استعلام فرعي في هذا الفحص: إن أعاد الاستعلام الفرعي قيمة NULL واحدة، لا يعيد NOT IN أي صف وينجح الفحص بصمت. أما NOT EXISTS وLEFT JOIN … IS NULL فلا يعانيان هذه المشكلة.

-- Items whose order does not exist
SELECT oi.order_item_id, oi.order_id
FROM order_items oi
LEFT JOIN orders o ON o.order_id = oi.order_id
WHERE o.order_id IS NULL;

-- Payments whose order does not exist
SELECT p.payment_id, p.order_id
FROM payments p
LEFT JOIN orders o ON o.order_id = p.order_id
WHERE o.order_id IS NULL;

-- The reverse: orders that have no items at all
SELECT o.order_id, o.status, o.created_at
FROM orders o
LEFT JOIN order_items oi ON oi.order_id = o.order_id
WHERE oi.order_item_id IS NULL;

-- The same check written with NOT EXISTS (safe when NULLs are present)
SELECT o.order_id
FROM orders o
WHERE NOT EXISTS (
  SELECT 1 FROM order_items oi WHERE oi.order_id = o.order_id
);

كشف التكرار بـ GROUP BY … HAVING COUNT(*) > 1

جمّع حسب القيمة التي يجب أن تكون فريدة واحتفظ بالمجموعات التي تتكرر أكثر من مرة. وحّد القيم أولاً حين يعدّ العمل الصيغ المختلفة شيئاً واحداً: LOWER وTRIM يلتقطان رسائل البريد التي تختلف في حالة الأحرف أو المسافات فقط. قيد UNIQUE على العمود الخام لا يمنع ذلك — مع أن ترتيبات المقارنة (Collations) الافتراضية غير الحساسة لحالة الأحرف في MySQL تعدّ «Layla.H@example.com» و«layla.h@example.com» متساويين، بينما يقارن PostgreSQL النصوص بحساسية لحالة الأحرف.

التكرار كذلك عَرَض لغياب عدم تكرار الأثر (Idempotency): زر نُقر مرتين أو طلب أُعيد فأنشأ طلبين أو حصّل دفعة واحدة مرتين. وإن كان تصميمك يسمح بتقسيم الدفع، فقارن مجموع المحصَّل بإجمالي الطلب (R2) بدل عدّ الصفوف.

-- Emails that differ only in letter case or surrounding spaces
SELECT LOWER(TRIM(email)) AS email_key, COUNT(*) AS copies
FROM customers
GROUP BY LOWER(TRIM(email))
HAVING COUNT(*) > 1;

-- List the duplicate rows themselves, grouped together
SELECT c.customer_id, c.email, c.created_at
FROM customers c
JOIN (
  SELECT LOWER(TRIM(email)) AS email_key
  FROM customers
  GROUP BY LOWER(TRIM(email))
  HAVING COUNT(*) > 1
) d ON d.email_key = LOWER(TRIM(c.email))
ORDER BY d.email_key, c.customer_id;

-- An order charged more than once
SELECT order_id, COUNT(*) AS captured_payments, SUM(amount) AS captured_total
FROM payments
WHERE status = 'CAPTURED'
GROUP BY order_id
HAVING COUNT(*) > 1;

فحوص NULL ونطاقات التواريخ

تعني NULL «غير معروف»، وأي مقارنة معها — بما في ذلك column = NULL — ليست صحيحة ولا خاطئة، فتسقط هذه الصفوف من النتيجة بصمت. افحص دائماً بـ IS NULL أو IS NOT NULL. وتذكّر أن COUNT(column) يتخطى قيم NULL بينما يعدّ COUNT(*) الصفوف، وأن النص الفارغ ليس NULL في PostgreSQL ولا MySQL ولا SQLite (بينما يعامله Oracle Database على أنه NULL).

في التواريخ استخدم نطاقات نصف مفتوحة: created_at >= اليوم الأول AND created_at < اليوم الأول من الفترة التالية. BETWEEN بتاريخ نهاية 2026-09-30 يفوّت كل ما بعد منتصف ليل يوم 30 حين يحمل العمود وقتاً. وتأكد أن طرفي المقارنة يستخدمان المنطقة الزمنية نفسها؛ فمقارنة CURRENT_TIMESTAMP في منطقة بقيم مخزّنة في منطقة أخرى تنتج صفوف «مستقبلية» كاذبة أو تخفي صفوفاً حقيقية.

-- Required text that is NULL or blank
SELECT customer_id, email
FROM customers
WHERE full_name IS NULL OR TRIM(full_name) = '';

-- R3: captured payments without a payment time
SELECT payment_id, order_id
FROM payments
WHERE status = 'CAPTURED' AND paid_at IS NULL;

-- R3: payments recorded before their order existed
SELECT p.payment_id, o.order_id, o.created_at, p.paid_at
FROM payments p
JOIN orders o ON o.order_id = p.order_id
WHERE p.paid_at < o.created_at;

-- Timestamps in the future (clock or time-zone defects)
SELECT order_id, created_at
FROM orders
WHERE created_at > CURRENT_TIMESTAMP;

-- One calendar month as a half-open range
SELECT COUNT(*) AS september_orders
FROM orders
WHERE created_at >= '2026-09-01' AND created_at < '2026-10-01';

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

فروق اللهجات التي تكسر الاستعلامات المحمولة

يعرّف معيار SQL الدولي ISO/IEC 9075 اللغة؛ وكل محرك ينفّذه بدرجة مختلفة ويضيف صياغته الخاصة. تتجنب الفحوص أعلاه هذه الفروق، لكن هذه أكثرها مصادفةً للمختبِرين حين ينسخون استعلاماً من مشروع إلى آخر:

• حدّ الصفوف — LIMIT 50 في PostgreSQL وMySQL وSQLite؛ وSELECT TOP (50) في SQL Server؛ والصيغة القياسية FETCH FIRST 50 ROWS ONLY في PostgreSQL وفي Oracle Database 12c وما بعده.
• دمج النصوص — || في PostgreSQL وSQLite وOracle؛ وفي MySQL تعني || عملية OR منطقية افتراضياً، فاستخدم CONCAT() المتوفرة في PostgreSQL وMySQL وSQL Server.
• حساب التواريخ — CURRENT_DATE - INTERVAL '7 days' في PostgreSQL، وCURRENT_DATE - INTERVAL 7 DAY في MySQL، وdate('now', '-7 days') في SQLite، وDATEADD(day, -7, CAST(GETDATE() AS date)) في SQL Server. التواريخ الحرفية بصيغة ISO مثل '2026-09-01' هي الخيار الأكثر قابلية للنقل.
• اقتطاع الطابع الزمني إلى يوم — CAST(created_at AS DATE) في PostgreSQL وMySQL وSQL Server؛ وdate(created_at) في SQLite.
• مقارنة النصوص — يقارن PostgreSQL النصوص بحساسية لحالة الأحرف؛ وترتيبات المقارنة الافتراضية في MySQL غير حساسة لها؛ والمساواة = في SQLite حساسة لها، بينما LIKE فيه غير حساس لحالة الأحرف في حروف ASCII فقط.
• اقتباس المعرّفات — "علامات تنصيص مزدوجة" في المعيار وPostgreSQL وSQLite؛ و`backticks` (علامة الاقتباس المعكوسة) في MySQL؛ و[أقواس معقوفة] في SQL Server.
• SELECT دون FROM — يقبله PostgreSQL وMySQL وSQLite وSQL Server؛ ويحتاج Oracle Database تقليدياً إلى FROM dual.

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

من استعلامات عابرة إلى مجموعة فحوص قابلة لإعادة الاستخدام

حين يجد استعلام عيباً، احتفظ به. مجلد من الفحوص المسمّاة، يعيد كل منها صفر صفوف حين تصمد القاعدة، يصبح مجموعة اختبار انحدار (Regression) للبيانات: شغّلها بعد النشر وبعد الترحيلات وعلى جدول زمني في Staging، واربطها بالاختبارات الآلية بحيث يتبع كل استدعاء API التحقق المطابق في قاعدة البيانات.

كثيراً ما تبدأ المقارنات بين الأنظمة بقائمة معرّفات مصدَّرة من نظام آخر. حوّل القائمة إلى جدول مشتق أو عبارة IN واربطها ببياناتك كما في المثال أدناه؛ ويُنتج مولّدا VALUES وIN في أدوات متقن صياغة القائمة من القيم الملصقة.

• فحص واحد لكل قاعدة، باسم القاعدة — مثلاً orders_total_matches_items.
• صفر صفوف يعني نجاحاً؛ وأي صفوف هي الدليل الذي ترفقه بتقرير الخطأ مع الاستعلام.
• للقراءة فقط: الفحص لا يعدّل البيانات أبداً.
• محدود: رشّح بالتاريخ أو الدفعة كي يبقى الفحص سريعاً على الجداول الكبيرة.
• محفوظ في نظام الإصدارات بجانب الترحيلات ويُراجع كالشيفرة.

-- Ids exported from the invoicing service that the order database does not have.
-- PostgreSQL and SQLite syntax; MySQL 8.0.19+ writes VALUES ROW(1042), ROW(1043), ...
WITH exported (order_id) AS (
  VALUES (1042), (1043), (1044), (1051)
)
SELECT e.order_id
FROM exported e
LEFT JOIN orders o ON o.order_id = e.order_id
WHERE o.order_id IS NULL;

جرّبها: مولّد قوائم SQL VALUES جرّبها: مولّد عبارات SQL IN جرّبها: محوّل CSV إلى SQL جرّبها: محوّل JSON إلى SQL

الأسئلة الشائعة

المراجع

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