عمليات CRUD

لماذا يهم

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

وCRUD قائمة تغطية بسيطة أيضاً. لكل نوع من السجلات تتعامل معه الميزة اسأل: هل توجد العمليات الأربع؟ ومن يحق له تنفيذ كل منها؟ وهل اختُبرت كل منها؟ فالإنشاء والقراءة يُمارَسان في كل اختبار تقريباً لأن الاختبارات الأخرى تحتاج إلى بيانات، أما التحديث والحذف فلا يُختبران إلا إذا خطّط لهما أحد، وهما العمليتان اللتان قد تُضيّعان البيانات أو تكشفانها.

العمليات الأربع وما يجب أن تفعله كل منها

لكل عملية أثر متوقَّع على البيانات المخزّنة، وهذا الأثر هو ما تختبره. والمفتاح الأساسي (Primary key) من الدرس السابق يربط العمليات الأربع: الإنشاء يمنح السجل مفتاحه، والقراءة والتحديث والحذف تستخدمه لتصل إلى سجل واحد بالضبط.

• الإنشاء (Create): سجل جديد واحد بمفتاح أساسي جديد، وكل حقل مُرسَل في العمود الصحيح، مع القيم التي يضبطها النظام بنفسه، مثل الحالة الافتراضية وcreated_at.
• القراءة (Read): تُعاد البيانات المخزّنة كما هي، سجلاً واحداً بمفتاحه أو قائمة مرشَّحة، والقراءة لا تغيّر شيئاً.
• التحديث (Update): تتغيّر الحقول المقصودة في السجل المقصود، ويبقى كل ما عداها كما كان، ويتقدّم updated_at إن وُجد في الجدول.
• الحذف (Delete): يختفي السجل من المنتج. أما في قاعدة البيانات فإما أن يُزال (الحذف الفعلي، Hard delete)، أو يبقى ويُعلَّم، مثلاً بطابع زمني في deleted_at (الحذف المنطقي، Soft delete). والحذف الفعلي لصف تشير إليه صفوف أخرى يتبع قاعدة الحذف في المفتاح الأجنبي التي تعلّمتها في الدرس السابق: تُحذف الصفوف المرتبطة معه (CASCADE)، أو تبقى ويصبح مرجعها NULL (SET NULL)، أو يُرفض الحذف (RESTRICT أو NO ACTION). أما الحذف المنطقي فهو تحديث، فلا تُطبَّق أي قاعدة حذف، وعلى التطبيق نفسه أن يعالج الصفوف المرتبطة.

عملية واحدة في ثلاث طبقات: الواجهة وHTTP وSQL

النقرة في الواجهة ترسل طلب HTTP إلى API، وتنفّذ API جملة SQL واحدة أو أكثر. ويحدد طلب HTTP طريقةً (Method) هي الإجراء المطلوب، ومساراً هو الهدف: فالطلب GET /contacts/7 يطلب جهة الاتصال 7، وتحمل الاستجابة رمز حالة مثل 200 OK. ويرسل PUT السجل الجديد كاملاً، بينما يرسل PATCH الحقول التي تتغيّر فقط. وفي جانب SQL تضيف INSERT صفوفاً، وتقرأ SELECT الصفوف، وتغيّر UPDATE قيماً في صفوف موجودة، وتحذف DELETE صفوفاً؛ ويقصر شرط WHERE أثر الجملة على الصفوف التي تستوفيه.

والربط المعتاد في واجهات REST، أي الواجهات المبنية على أسلوب شائع يسمّي فيه كل مسار سجلاً أو مجموعة من السجلات، هو: الإنشاء يقابله POST وINSERT، والقراءة GET وSELECT، والتحديث PUT أو PATCH وUPDATE، والحذف DELETE في الطبقتين. وهذه الجمل الأربع هي جوهر ما يُسمّى عادةً لغة معالجة البيانات (DML) في SQL. ويتعمّق درسا «طرق HTTP» و«أساسيات REST API» في الطلبات، ويشرح الدرس التالي جملة SELECT.

هذا الربط عُرف وليس قاعدة، ومواضع الاختلاف فيه هي حيث ينبغي أن تبحث الاختبارات. فطلب POST /orders واحد قد ينفّذ INSERT للطلب وآخر لكل صنف. وزر الحذف قد ينفّذ UPDATE يضبط deleted_at؛ فـRFC 9110 يعرّف DELETE بأنه إزالة الربط بين عنوان URI والمورد، لا وعداً بمسح البيانات. وزر الإلغاء قد يرسل POST /appointments/7/cancel، وهو تحديث بلغة CRUD. وعقد API أو المطور أو قاعدة البيانات يخبرك بما يحدث فعلاً.

CRUD    UI action        HTTP request        SQL statement
------  ---------------  ------------------  --------------------------------------------
Create  Add contact      POST /contacts      INSERT INTO contacts (...) VALUES (...)
Read    Open contact 7   GET /contacts/7     SELECT * FROM contacts WHERE id = 7
Update  Edit phone       PATCH /contacts/7   UPDATE contacts SET phone = ... WHERE id = 7
Delete  Delete contact   DELETE /contacts/7  DELETE FROM contacts WHERE id = 7

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

تحقّق في المنتج أولاً، ثم في قاعدة البيانات

نفّذ كل عملية كما يفعل المستخدم أو العميل، عبر الواجهة أو API. فكتابة الصفوف مباشرة في قاعدة البيانات تتجاوز التحقق من صحة المدخلات ومنطق التطبيق اللذين يُفترض أنك تختبرهما، وجمل INSERT المباشرة لتجهيز الشروط المسبقة. ثم افحص النتيجة في النقاط أدناه. وفي الاختبارات السلبية، كالمدخلات غير الصالحة أو مستخدم بلا صلاحية، يجب ألا تُظهر قاعدة البيانات أي تغيير، ولا حتى صفاً جزئياً.

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

• الاستجابة: الرسالة على الشاشة، أو رمز الحالة وجسم الاستجابة من API.
• القراءة اللاحقة عبر المنتج: أعد تحميل الصفحة أو أرسل طلب GET منفصلاً. فهي تكشف شاشة تكرّر مدخلاتك فقط وبيانات قديمة من الذاكرة المؤقتة (Cache)؛ ومقارنة الاستجابة قبل التحديث وبعده تُظهر كل حقل تغيّر.
• قاعدة البيانات: استعلم عن الصف بمفتاحه الأساسي لترى ما قد لا يعرضه المنتج: ربط الحقول بالأعمدة، والقيم الافتراضية، والطوابع الزمنية، وعلامات الحذف المنطقي، والتقريب، وترميز النص العربي.
• ما يجاور الهدف: الإنشاء أضاف صفاً واحداً بالضبط؛ والتحديث لم يمسّ الصفوف الأخرى ولا الأعمدة غير المقصودة؛ والحذف عامل الصفوف المرتبطة كما صُمّم، والسجل اختفى من القوائم ونتائج البحث والمجاميع.

جرّبها: مختبِر REST API جرّبها: مقارنة JSON جرّبها: مدقّق استعلامات SQL

مثال تطبيقي: تغيير موعد

المتطلب: «يستطيع المريض نقل موعد قادم إلى فترة شاغرة أخرى لدى الطبيب نفسه، وتصبح الفترة القديمة شاغرة من جديد». هذه بالنسبة إلى المستخدم عملية تحديث واحدة، لكن في قاعدة البيانات ينبغي أن يتغيّر جدولان.

يسجّل المختبِر الحالة أولاً: الموعد 7 للمريض 1203 في الفترة 41 الساعة ⁦09:00⁩، وهو الموعد المحجوز الوحيد لهذا المريض. ثم يغيّر الموعد إلى الساعة ⁦10:30⁩ عبر الواجهة، فترسل طلب PATCH، ويعيد تحميل «مواعيدي» التي يجب أن تعرض ⁦10:30⁩، ويشغّل الاستعلامات في نهاية هذا القسم. اقرأ كلاً منها على أنه «اعرض هذه الأعمدة من الصفوف المطابقة»: فالعبارة IN (41, 58) تطابق أياً من المعرّفين، والدالة COUNT(*) تعيد عدد الصفوف المطابقة. ويكشف كل استعلام عيباً مختلفاً:

• الاستعلام 1: إن تغيّر status أو patient_id فقد لمس التحديث أعمدة لا ينبغي أن يلمسها؛ وإن بقي slot_id على 41 فشاشة التأكيد لم تعرض إلا ما أُرسل.
• الاستعلام 2: إن بقيت الفترة 41 محجوزة فلن يستطيع أحد حجز الساعة ⁦09:00⁩ مجدداً؛ وإن لم تُعلَّم الفترة 58 محجوزةً فقد يحجز مريض آخر الساعة ⁦10:30⁩ أيضاً. لا يرى المريض أي خلل، ولا يظهر ذلك إلا في قاعدة البيانات أو في ما يراه مريض آخر.
• الاستعلام 3: إن أدرجت API موعداً جديداً بدلاً من تحديث الصف 7 فالعدد 2، وهو حجز مزدوج لن تُظهره شاشة التأكيد.

-- Before: appointment 7 (patient 1203) is booked in slot 41 at 09:00
-- UI: "Reschedule" to 10:30 -> PATCH /api/appointments/7 {"slot_id": 58} -> 200 OK

-- 1. The appointment changed, and only the intended columns
SELECT id, patient_id, slot_id, status, updated_at
FROM appointments
WHERE id = 7;
-- expected: slot_id 58, patient_id 1203, status 'booked', updated_at later

-- 2. Both slots changed
SELECT id, starts_at, is_booked
FROM slots
WHERE id IN (41, 58);
-- expected: 41 is_booked false, 58 is_booked true

-- 3. No second appointment was created
SELECT COUNT(*)
FROM appointments
WHERE patient_id = 1203 AND status = 'booked';
-- expected: 1, the same as before

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

أسئلة شائعة

المراجع

• RFC 9110: HTTP SemanticsIETF · 2022معاني أساليب HTTP وحقول الترويسات ورموز الحالة والتفاوض على المحتوى، بغضّ النظر عن إصدار البروتوكول.
• ISO/IEC 9075-1:2023 — Information technology — Database languages SQL — Part 1: Framework (SQL/Framework)ISO/IEC · 2023الجزء الإطاري من معيار SQL الدولي، الذي تنفّذه لهجات PostgreSQL وMySQL وSQLite وغيرها بدرجات متفاوتة.
• SQL As Understood By SQLiteSQLiteقواعد SQL التي يقبلها SQLite، عبارة تلو الأخرى، مع مخططات نحوية.
• RFC 5789: PATCH Method for HTTPIETF · 2010أسلوب PATCH للتحديثات الجزئية، مقابل PUT الذي يستبدل المورد كاملاً.