# CASE WHEN في SQL: دليل عملي لتحليل البيانات

> تحكم في المنطق الشرطي مع دليلنا إلى الحالات when sql. تعلم الصياغة النحوية والأمثلة الواقعية وكيفية تحويل البيانات إلى رؤى تجارية.

Source: https://www.electe.net/ar/%D8%A7%D9%84%D9%85%D9%86%D8%B4%D9%88%D8%B1/case-when-sql

Site guide: https://www.electe.net/ar/llms.txt

إذا كنت تعمل مع البيانات، فإن جملة `CASE WHEN`** في SQL** تشبه سكين الجيش السويسري لاستعلاماتك. إنها واحدة من تلك الجمل التي، بمجرد اكتشافها، تتساءل كيف كنت تستغني عنها. تتيح لك إدراج منطق شرطي (مثل "إذا حدث هذا، فافعل ذلك") مباشرة في تحليلك

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

## ما الذي يفعله CASE WHEN في SQL بالفعل؟

تخيل تدفقًا فوضويًا من البيانات، مثل صف من السيارات على الطريق السريع. بدون قواعد، إنه مجرد طابور طويل من المركبات. تعمل `CASE WHEN` كنظام فرز ذكي: السيارات الحمراء إلى اليسار، الزرقاء إلى اليمين، وكل الباقي يواصل طريقه مباشرة.

وبالمثل، في SQL، يمكنك الحصول على البيانات وتحويلها، بعبارة واحدة، إلى معلومات نظيفة ومنظمة وجاهزة للتحليل.

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

- **تنظيف في الوقت الفعلي:** صحح ووحّد القيم أثناء الاستخراج
- **تصنيف ديناميكي:** قسّم العملاء والمنتجات والمعاملات حسب الأداء أو التاريخ أو القيمة
- **إثراء سياقي:** أنشئ أعمدة بحالة العمل ("عميل مخلص"، "معرض للخطر")

باختصار، `CASE WHEN` هو الخطوة الأولى لتحويل بياناتك من مجرد أرقام إلى رؤى استراتيجية. إنه الجسر الذي يربط جدولًا خامًا بتقرير يتيح لك اتخاذ قرارات أفضل.

في الأقسام التالية، سنرى الصيغة الدقيقة وأمثلة عملية لإتقان هذه الجملة وحل مشاكل تجارية ملموسة.

## تعلم بناء جملة case when خطوة بخطوة

لإتقان المنطق الشرطي في SQL، الأفضل هو البدء من الأساسيات وفهم بنية `CASE WHEN` جيدًا. لنبدأ بشكلها الأكثر مباشرة، "**CASE البسيط**"، المثالية لمن يخطو خطواته الأولى.

هذه النسخة مثالية عندما تحتاج إلى التحقق من قيم عمود واحد وتعيين نتيجة مختلفة لكل منها. بسيطة، واضحة، فعالة.

### هيكل CASE البسيط

الصياغة بديهية بشكل مدهش. لنأخذ مثالاً عمليًا: تخيل أن لديك عمودًا `StatoOrdine` بقيم نصية مثل 'Spedito' (تم الشحن)، 'In Lavorazione' (قيد المعالجة) أو 'Annullato' (ملغى). لتقاريرك، سيكون من الأنسب بكثير أن يكون لديك رمز رقمي، أليس كذلك؟

إليك كيفية تحويل هذا النص إلى أرقام:

`SELECTIDOrdine,StatoOrdine,CASE StatoOrdineWHEN 'Spedito' THEN 1WHEN 'In Lavorazione' THEN 2WHEN 'Annullato' THEN 3ELSE 0 -- Questo è il nostro paracaduteEND AS StatoNumericoFROM Vendite;`

كما ترى، تشير `CASE` إلى العمود المراد فحصه (`StatoOrdine`). كل `WHEN` يتحقق مما إذا كانت القيمة مساوية لشيء محدد، و`THEN` يعيّن النتيجة المقابلة.

جملة `ELSE` أساسية. إنها نوع من شبكة الأمان: إذا لم يتحقق أي من شروط `WHEN`، فإنها تعيّن قيمة افتراضية (هنا، `0`)، مما ينقذك من نتائج `NULL` المزعجة. إذا أردت رؤية جداول مماثلة في العمل، يمكنك إلقاء نظرة على هذا [مثال قاعدة بيانات](https://www.electe.net/post/esempio-di-database).

### قوة CASE المطلوبة

"**CASE المُبحَث**" (أو _Searched CASE_) هو بمثابة صندوق أدوات حقيقي. هنا تنطلق المرونة الحقيقية لهذه الجملة، لأنك لم تعد مقيدًا بفحص عمود واحد فقط.

مع CASE المُبحَث يمكنك بناء شروط معقدة، تقيّم عدة حقول في آن واحد باستخدام معاملات منطقية مثل `AND` و`OR`، أو معاملات مقارنة مثل `>` و`<`. إنها الأداة المثالية لتطبيق منطق أعمال متشعب مباشرة في استعلامك.

لا يقتصر CASE المُبحَث على فحص بسيط للمساواة. إنه يقيّم ما إذا كان **شرط ما في مجمله صحيحًا**، مما يمنحك القدرة على إنشاء قواعد متطورة تعكس ديناميكيات شركتك الفعلية.

لنفترض أنك تريد تصنيف المبيعات حسب المبلغ وفئة المنتج. إليك كيفية القيام بذلك:

`SELECTIDProdotto,Prezzo,Categoria,CASEWHEN Prezzo > 1000 AND Categoria = 'Elettronica' THEN 'Vendita Premium'WHEN Prezzo > 500 THEN 'Vendita Alto Valore'ELSE 'Vendita Standard'END AS SegmentoVenditaFROM Vendite;`

هذه القدرة على تشبيك شروط متعددة هي ما يجعل `CASE WHEN` ركيزة لا غنى عنها لأي تحليل بيانات يريد تجاوز السطح.

فيما يلي جدول يلخص الاختلافات الرئيسية بين الصيغتين، لمساعدتك في اختيار الصيغة المناسبة في الوقت المناسب.

### مقارنة بين بناء جملة case البسيطة و case المطلوبة

يقارن هذا الجدول بشكل مباشر بين الشكلين الرئيسيين لعبارة CASE، ويوضح متى يتم استخدام كل شكل، ويعرض هيكلهما جنبًا إلى جنب لفهمهما على الفور.

الاختيار بين الاثنين ليس مسألة "أفضل" أو "أسوأ"، بل مسألة استخدام الأداة الأنسب للعمل المطلوب. للتحكم المباشر والسريع، فإن CASE Semplice مثالي؛ أما بالنسبة للمنطق التجاري المعقد، فإن CASE Cercato هو الخيار الأمثل.

بصريًا، يمكنك تخيل `CASE WHEN` كشجرة قرار تأخذ البيانات الخام وتوجهها نحو فئات محددة جيدًا، مما يجلب النظام والوضوح إلى تحليلاتك.

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

## كيفية تحويل البيانات الأولية إلى رؤى تجارية

الآن بعد أن لم تعد الصياغة تخفي أي أسرار، حان الوقت لرؤية `CASE WHEN` في العمل ضمن سيناريوهات أعمال حقيقية. تظهر القوة الحقيقية لهذه الجملة عندما تستخدمها لتحويل الأرقام والرموز إلى رؤى ملموسة، إلى توجيهات استراتيجية حقيقية لشركتك.

سنركز على تطبيقين أساسيين: تقسيم العملاء وتحليل هامش الربح للمنتجات. هذه هي الخطوة الأولى والحاسمة لاتخاذ قرارات تستند إلى البيانات وليس إلى الحدس.

### تقسيم العملاء حسب القيمة

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

مع `CASE WHEN`، يمكنك إنشاء هذا التقسيم مباشرة في استعلامك. تخيل أن لديك جدول `FatturatoClienti` بأعمدة `ClienteID` و`TotaleAcquistato`.

إليك كيف يمكنك تصنيف كل عميل دفعة واحدة:

`SELECTClienteID,TotaleAcquistato,CASEWHEN TotaleAcquistato > 5000 THEN 'Alto Valore'WHEN TotaleAcquistato BETWEEN 1000 AND 5000 THEN 'Medio Valore'ELSE 'Basso Valore'END AS SegmentoClienteFROM FatturatoClientiORDER BY TotaleAcquistato DESC;`

بهذه الجملة الواحدة، أضفت عمودًا جديدًا، `SegmentoCliente`، يُثري البيانات الخام بسياق تجاري فوري. الآن يمكنك بسهولة حساب عدد العملاء لديك في كل شريحة أو تحليل سلوكياتهم الشرائية المحددة، مما يحسّن العائد على الاستثمار (ROI) لحملاتك التسويقية.

### حساب وتصنيف هامش الربح للمنتجات

استخدام استراتيجي آخر لـ **case when sql** هو تحليل الربحية. لا تُساهم جميع المنتجات في الأرباح بنفس القدر. تصنيف العناصر بناءً على هامش ربحها يساعدك على تحديد أين تركز جهودك، وأيها تضعه في العروض الترويجية، وأيها قد يكون من الأفضل التخلي عنه.

لنأخذ جدول `Prodotti` الذي يحتوي على `PrezzoVendita` و`CostoAcquisto`. أولًا نحسب هامش الربحية، ومباشرة بعدها نصنّفه.

`SELECTNomeProdotto,PrezzoVendita,CostoAcquisto,CASEWHEN (PrezzoVendita - CostoAcquisto) / PrezzoVendita > 0.5 THEN 'Alta Marginalità'WHEN (PrezzoVendita - CostoAcquisto) / PrezzoVendita BETWEEN 0.2 AND 0.5 THEN 'Media Marginalità'ELSE 'Bassa Marginalità'END AS CategoriaMarginalitaFROM ProdottiWHERE PrezzoVendita > 0; -- Fondamentale per evitare divisioni per zero`

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

### من SQL إلى الأتمتة باستخدام منصات التحليلات

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

هذا لا يجعل SQL عتيقًا، بل على العكس، يُعزز قيمته. المنطق يبقى نفسه، لكن التنفيذ يصبح آليًا ومتاحًا لكل الفريق. النتيجة عائد استثمار فوري: يمكن لفرق الأعمال استكشاف البيانات وإنشاء شرائح معقدة دون الاعتماد على قسم تقنية المعلومات، مما يُسرّع بشكل كبير المسار الذي يقود [**من البيانات الخام إلى المعلومات المفيدة لاتخاذ القرارات**](https://www.electe.net/post/dai-dati-grezzi-alle-informazioni-utili-un-viaggio-step-by-step). أما المحللون، فيتفرغون بدورهم لمعالجة مشكلات أكثر تعقيدًا، وهم على يقين من أن التحليلات الروتينية تُدار تلقائيًا.

## تقنيات متقدمة مع CASE WHEN

حسنًا، الآن بعد أن اكتسبت الثقة في التقسيم الأساسي، حان الوقت لرفع المستوى. لنكتشف معًا كيف نُحوّل `CASE WHEN` إلى أداة للتحليلات المعقدة والتقارير المتقدمة، كل ذلك ضمن استعلام واحد.

### إنشاء "جدول محوري" باستخدام وظائف التجميع

من أقوى التقنيات هي الجمع بين `CASE WHEN` ودوال التجميع مثل `SUM`، `COUNT` أو `AVG`. هذه الحيلة تتيح لك إنشاء "جداول محورية" مباشرة في SQL، وحساب مقاييس محددة لشرائح مختلفة دون الحاجة إلى تشغيل استعلامات متعددة.

لنفترض أنك تريد مقارنة إجمالي المبيعات التي حققها العملاء "المتميزون" مع إجمالي المبيعات التي حققها العملاء "العاديون" في نفس التقرير. يمكنك القيام بذلك دفعة واحدة.

`SELECTSUM(CASE WHEN SegmentoCliente = 'Premium' THEN Fatturato ELSE 0 END) AS FatturatoPremium,SUM(CASE WHEN SegmentoCliente = 'Standard' THEN Fatturato ELSE 0 END) AS FatturatoStandardFROM Vendite;`

ماذا يحدث هنا؟ دالة `SUM` تجمع `Fatturato` _فقط_ عندما يكون الشرط المحدد في `WHEN` صحيحًا. بالنسبة لجميع الصفوف الأخرى، تجمع صفرًا. إنها طريقة فعّالة للغاية لتجميع البيانات عبر أبعاد متعددة في آن واحد، مما يوفر الوقت ويقلل التعقيد.

### إدارة منطق متعدد المستويات باستخدام الحالات المتداخلة

أحيانًا، لا يكون منطق الأعمال بهذه البساطة الخطية. ربما تحتاج إلى تقسيم العملاء ليس فقط بناءً على مقدار إنفاقهم، بل أيضًا بناءً على مدى تكرار شرائهم. هنا يدخل في اللعب منطق متعدد المستويات، يمكنك تنفيذه من خلال **تضمين **`CASE`** داخل آخر**.

`CASE` متداخل يتيح لك إنشاء فئات فرعية دقيقة. على سبيل المثال، قد نرغب في تقسيم عملائنا "ذوي القيمة العالية" إلى مجموعتين إضافيتين: "الأوفياء" و"العرضيون".

`SELECTClienteID,TotaleSpeso,NumeroAcquisti,CASEWHEN TotaleSpeso > 5000 THENCASEWHEN NumeroAcquisti > 10 THEN 'Alto Valore - Fedele'ELSE 'Alto Valore - Occasionale'ENDWHEN TotaleSpeso > 1000 THEN 'Medio Valore'ELSE 'Basso Valore'END AS SegmentoDettagliatoFROM RiepilogoClienti;`

**انتبه للوضوح:** على الرغم من قوتها الكبيرة، يمكن أن تصبح جمل `CASE` المتداخلة كابوسًا من حيث القراءة والصيانة. إذا تجاوز المنطق مستويين من العمق، توقف. ربما يكون من الأفضل تقسيم المشكلة إلى عدة خطوات، ربما باستخدام تعبيرات الجدول الشائعة (CTE) لجعل كل شيء أكثر وضوحًا.

### التعامل مع الاختلافات بين قواعد البيانات المختلفة

على الرغم من أن `CASE WHEN` هو معيار SQL راسخ، توجد اختلافات تنفيذ طفيفة بين أنظمة إدارة قواعد البيانات المختلفة (DBMS). معرفتها أمر أساسي لكتابة كود قابل للنقل.

- **MySQL:** متوافق تمامًا مع المعيار. يمكنك استخدام `CASE` في أي مكان تقريبًا: في جمل `SELECT`، `WHERE`، `GROUP BY` و`ORDER BY`.
- **PostgreSQL:** يتبع المعيار بصرامة كبيرة ويوفر إدارة قوية جدًا لأنواع البيانات، لذا فإن تحويلات النوع داخل `THEN` تُدار بطريقة يمكن التنبؤ بها.
- **SQL Server:** يدعم `CASE` بشكل ممتاز، لكنه يوفر أيضًا الدالة غير القياسية `IIF(condizione, valore_se_vero, valore_se_falso)`. `IIF` هي اختصار للمنطق الثنائي البسيط (شرط واحد فقط `IF/ELSE`)، لكن `CASE WHEN` يبقى الخيار الأفضل من حيث الوضوح وقابلية النقل.

معرفة هذه الفروق الدقيقة ستساعدك على كتابة استعلامات **case when sql** لا تعمل فقط بشكل صحيح، بل تكون أيضًا قوية وقابلة للتكيف بسهولة مع سياقات تقنية مختلفة.

## الأخطاء الشائعة وكيفية تحسين أداء استعلاماتك

كتابة `CASE WHEN` تعمل هي مجرد الخطوة الأولى. القفزة النوعية الحقيقية تأتي عندما تتعلم كيف تجعلها ليست فقط صحيحة، بل أيضًا سريعة ومقاومة للأخطاء. استعلام بطيء أو مليء بالأخطاء يمكن أن يُفسد تقاريرك ويُبطئ قرارات العمل.

لنرى معًا كيف يمكن تحسين التقنية وتجنب الأخطاء الشائعة وتحسين أداء تحليلاتك.

### انتبه إلى الترتيب: حيلة صغيرة تحدث فرقًا كبيرًا

إليك تفصيلة كثيرًا ما يُستهان بها: في جملة `CASE WHEN`، تقوم قاعدة البيانات بتحليل الشروط بالترتيب الدقيق الذي كتبتها به. بمجرد أن تجد شرطًا صحيحًا، تتوقف وتُرجع النتيجة.

هذا السلوك له تأثير كبير على الأداء، خاصة عند العمل على جداول تحتوي على ملايين الصفوف.

الحيلة؟ **ضع دائمًا في المقدمة الشروط التي تعتقد أنها ستتحقق في أغلب الأحيان**. بهذه الطريقة، سيبذل محرك قاعدة البيانات أقل جهد ممكن لمعظم الصفوف، مما يقلل بشكل كبير من وقت التنفيذ.

### أكثر الأخطاء شيوعًا (وكيفية تجنبها)

حتى المحللون الأكثر خبرة يقعون أحيانًا في بعض الأخطاء الكلاسيكية. ومعرفة هذه الأخطاء هي أفضل طريقة لاكتشافها على الفور وتصحيحها.

- **نسيان جملة **`ELSE`
هذا هو الخطأ رقم واحد. إذا حذفت `ELSE` ولم يتحقق أي من شروط `WHEN` الخاصة بك، فستكون النتيجة لذلك الصف `NULL`. هذه القيمة `NULL` غير المتوقعة يمكن أن تُحدث تأثيرًا متسلسلًا، مُخلّةً بالحسابات اللاحقة.
- **كود معرّض للخطر:**`SELECTPrezzo,CASEWHEN Prezzo > 100 THEN 'Alto'WHEN Prezzo > 50 THEN 'Medio'END AS FasciaPrezzo -- إذا كان Prezzo يساوي 40، تكون النتيجة NULLFROM Prodotti;`
- **الحل الآمن:**
أضف دائمًا `ELSE` كشبكة أمان لالتقاط جميع الحالات غير المتوقعة.`SELECTPrezzo,CASEWHEN Prezzo > 100 THEN 'Alto'WHEN Prezzo > 50 THEN 'Medio'ELSE 'Basso' -- ها هي شبكة الأمان لدينا!END AS FasciaPrezzoFROM Prodotti;`
- **أنواع بيانات متضاربة**
يجب أن تُرجع جميع التعبيرات بعد `THEN` نفس نوع البيانات (أو أنواعًا متوافقة). إذا حاولت خلط النصوص والأرقام والتواريخ في نفس العمود الناتج عن `CASE`، فستُرجع لك قاعدة البيانات خطأً.
- **شروط متداخلة**
هذا خطأ منطقي أكثر مكرًا. إذا كان لديك شروط متداخلة، تذكّر القاعدة الذهبية: فقط الشرط _الأول_ الذي يتحقق هو الذي يُنفَّذ. الترتيب هو كل شيء. إذا وضعت `WHEN TotaleAcquistato > 1000` قبل `WHEN TotaleAcquistato > 5000`، فلن يُصنَّف أي عميل أبدًا كـ 'VIP'، لأن الشرط الأول سيقوم دائمًا بـ"التقاطه" أولاً.

### هل هناك بدائل لـ CASE WHEN؟

على الرغم من أن **case when sql** هو المعيار العالمي - وغالبًا ما يكون الخيار الأفضل من حيث الوضوح والتوافق - إلا أن بعض لهجات SQL تقدم اختصارات.

في [SQL Server](https://www.microsoft.com/sql-server/)، على سبيل المثال، تجد الدالة `IIF(condizione, valore_se_vero, valore_se_falso)`. إنها مريحة لمنطق ثنائي بسيط، لكن `CASE` يبقى لا يُضاهى في التعامل مع الشروط المتعددة وفي وضوحه في السيناريوهات المعقدة.

في الغالبية العظمى من الحالات، التقيّد بالمعيار `CASE WHEN` هو الخيار الأكثر حكمة. فهو يضمن أن يفهم كودك أي شخص، وأن يعمل دون مفاجآت على منصات مختلفة.

## ما وراء CASE WHEN: عندما لا يكفي SQL

كتابة استعلامات CASE WHEN أمر مفيد. ولكن إذا وجدت نفسك تعيد كتابة نفس منطق التجزئة كل أسبوع للتقارير الشهرية، أو أسوأ من ذلك، إذا كان فريق التسويق الخاص بك يسألك "هل يمكنك إضافة هذا الجزء أيضًا؟" كل يومين، فأنت تواجه مشكلة في قابلية التوسع، وليس في SQL.

#### **عندما تصبح كتابة الاستعلامات هي عنق الزجاجة**

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

**المشكلة الحقيقية ليست في كتابة SQL**. المشكلة أنه بينما تكتب أنت الاستعلامات، شخص آخر في فريقك ينتظر البيانات لاتخاذ القرارات. وعندما تصل البيانات أخيرًا، غالبًا ما تكون النافذة المفيدة للتصرف قد ضاقت بالفعل.

ELECTE منصات مثل ELECTE هذا الأمر بالضبط: الترجمة من منطق الأعمال إلى الاستعلامات. هذا لا يلغي قيمة معرفة كيفية كتابة SQL - بل على العكس، ففهم ما يحدث تحت الغطاء يجعلك أكثر فعالية في استخدام أي أداة تحليلية. لكنه يخلصك من العمل المتكرر.

الفرق العملي: بدلاً من قضاء ساعات في كتابة واستكشاف أخطاء الاستعلامات لتقسيم العملاء إلى شرائح، يمكنك قضاء 5 دقائق في تحديد القواعد والوقت المتبقي في تحليل ما تعنيه تلك الشرائح بالنسبة للأعمال. هذا ليس سحرًا، إنه مجرد إزالة الاحتكاك بين "لدي سؤال" و"لدي إجابة".

إذا كنت تقضي نصف يومك في استخراج البيانات بدلاً من تحليلها، فربما تكون قد أدركت بالفعل أين يكمن العائق.

### من SQL اليدوي إلى الرؤية التلقائية

ELECTE منصات مثل ELECTE منطق CASE WHEN من خلال واجهات بدون كود. حدد قواعد التجزئة ببضع نقرات، دون كتابة سطر واحد من الكود. النتيجة: تحليلات كانت تستغرق ساعات في السابق تصبح جاهزة في دقائق، ويمكن لجميع أعضاء الفريق الوصول إليها دون الاعتماد على قسم تكنولوجيا المعلومات.

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

## الأسئلة المتكررة حول CASE WHEN

حتى بعد رؤية عدة أمثلة، من الطبيعي أن تبقى لديك بعض التساؤلات. دعنا نجيب على الأسئلة الأكثر شيوعًا التي تظهر عند البدء باستخدام `CASE WHEN`** في SQL**.

### ما الفرق بين CASE و IF في SQL؟

الفرق الأساسي: **قابلية النقل**. `CASE WHEN` جزء من معيار SQL (ANSI SQL)، مما يعني أن كودك سيعمل تقريبًا على أي قاعدة بيانات حديثة، من [PostgreSQL](https://www.postgresql.org/) و[MySQL](https://www.mysql.com/) إلى [SQL Server](https://www.microsoft.com/en-us/sql-server) و[Oracle](https://www.oracle.com/database/).

أما جملة `IF()`، فهي غالبًا دالة خاصة بلهجة معينة من SQL، مثل T-SQL الخاصة بـ SQL Server. وعلى الرغم من أنها قد تبدو أقصر لشرط ثنائي بسيط، إلا أن `CASE WHEN` هو خيار المحترفين لكتابة كود مقروء يعمل في كل مكان دون تعديلات.

### هل يمكنني استخدام CASE WHEN في جملة WHERE؟

بالتأكيد نعم. ليس الاستخدام الأكثر شيوعًا، لكن في سيناريوهات معينة يكون قويًا بشكل مذهل لإنشاء فلاتر شرطية معقدة. تخيل، على سبيل المثال، أنك تريد استخراج جميع العملاء "premium"، _أو_ فقط العملاء "standard" الذين لم يشتروا منذ أكثر من عام.

إليك كيف يمكنك ضبط المنطق:

`SELECT NomeCliente, UltimoAcquistoFROM ClientiWHERECASEWHEN Segmento = 'Premium' THEN 1WHEN Segmento = 'Standard' AND UltimoAcquisto < '2023-01-01' THEN 1ELSE 0END = 1;`

في الواقع، أنت تقول للقاعدة البيانات: "ضع في اعتبارك فقط الصفوف التي تعطي هذه المنطقية المعقدة النتيجة 1".

### كم عدد الشروط WHEN التي يمكن أن أحصل عليها؟

نظريًا، لا يفرض معيار SQL حدًا صارمًا على عدد جمل `WHEN`. لكن في الواقع، الاستعلام الذي يحتوي على عشرات الشروط يصبح كابوسًا من حيث القراءة والصيانة والتحسين.

إذا وجدت نفسك تكتب `CASE` لا ينتهي، اعتبر ذلك جرس إنذار. على الأرجح توجد طريقة أذكى لحل المشكلة، ربما باستخدام _lookup table_ (جدول تعيين) لجعل الاستعلام أنظف وأكثر كفاءة.

### كيف يتعامل CASE WHEN مع القيم NULL؟

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

في هذه الحالات، تصبح جملة `ELSE` أفضل صديق لك. تتيح لك التعامل بشكل نظيف ويمكن التنبؤ به مع جميع الحالات غير المشمولة بـ `WHEN`، بما في ذلك `NULL`. استخدمها لتعيين قيمة افتراضية وستتجنب الحصول على نتائج غير متوقعة في تحليلاتك.