شرح SQL: اللغة التي تطرح على بياناتك الأسئلة الصعبة

في جملة واحدة

لغة SQL (لغة الاستعلامات المهيكلة) هي لغة البرمجة العالمية لطرح الأسئلة (الاستعلامات أو queries) على قاعدة بيانات مهيكلة والحصول على إجابات في شكل جداول مرتبة وأنيقة.

المشكلة التي تحلها

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

في أوائل السبعينيات، كان باحثان لامعان في شركة IBM، هما دونالد تشامبرلين وريموند بويس، يعملان على نوع جديد من نماذج قواعد البيانات اقترحه إدغار ف. كود يسمى "النموذج العلائقي". كانت الفكرة الكبيرة هي تخزين البيانات في جداول بسيطة (أو "علاقات") وتحديد العلاقات بينها. وللتحدث مع هذا النوع الجديد من قواعد البيانات، أنشأوا لغة أطلقوا عليها اسم SEQUEL (لغة الاستعلامات الإنجليزية المهيكلة).

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

حلت SQL مشكلة "برج بابل" لقواعد البيانات. لقد أوجدت لغة مشتركة (lingua franca) تفصل بين ماذا تريد (البيانات التي تريدها) وكيفية الحصول عليها (التفاصيل التقنية الدقيقة لكيفية عثور محرك قاعدة البيانات عليها واسترجاعها). هذا يسمح للمطورين والمحللين بالتركيز على منطق أسئلتهم، وليس على الآليات الخاصة بنظام التخزين.

كيف تعمل من الداخل

في جوهرها، SQL هي لغة تعريفية (declarative). أنت لا تخبر قاعدة البيانات كيفية الحصول على البيانات خطوة بخطوة؛ أنت فقط تُعرّف البيانات التي تريدها. ثم يقوم مُحسِّن الاستعلامات (query optimizer) في قاعدة البيانات بتحديد الطريقة الأكثر كفاءة لتنفيذ طلبك. الأمر يشبه طلب البيتزا: أنت فقط تقول "أريد بيتزا بيبروني كبيرة"، ولا تقدم تعليمات مفصلة خطوة بخطوة لمحل البيتزا.

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

الجمل الأساسية: SELECT, FROM, WHERE

هذا هو الثالوث المقدس لاستعلامات SQL. تقريبًا كل استعلام لاسترداد البيانات ستكتبه سيحتوي على الأقل على SELECT و FROM.

• SELECT: تحدد الأعمدة (الحقول) التي تريد استرجاعها.
• FROM: تحدد الجدول الذي تسترجعها منه.
• WHERE: تفلتر الصفوف، بحيث تحصل فقط على تلك التي تطابق شرطًا معينًا.

تخيل جدول employees بسيط:

id	name	department	salary
1	Alice	Engineering	90000
2	Bob	Marketing	65000
3	Charlie	Engineering	110000

للعثور على أسماء جميع الموظفين في قسم الهندسة (Engineering)، ستكتب:

SELECT name, salary
FROM employees
WHERE department = 'Engineering';

ينظر محرك قاعدة البيانات إلى هذا، يجد جدول employees، يمسحه بحثًا عن الصفوف حيث قيمة عمود department هي 'Engineering'، ثم يسحب فقط عمودي name و salary لتلك الصفوف، ليعيد:

name	salary
Alice	90000
Charlie	110000

ربط النقاط: قوة JOIN

هنا يبرز الجزء "العلائقي" من "قاعدة البيانات العلائقية". نادرًا ما تكون جميع البيانات في جدول واحد ضخم. عادةً ما يتم تقسيمها إلى جداول منطقية لتجنب التكرار (وهو مفهوم يسمى التطبيع أو normalization). JOIN هي الطريقة التي تعيد بها تجميعها معًا في استعلام واحد.

دعنا نضيف جدول projects:

id	project_name	lead_employee_id
101	Project Phoenix	3
102	Project Chimera	1

هنا، lead_employee_id "يشير" إلى id في جدول employees. للحصول على قائمة بالمشاريع واسم قائد كل مشروع، لا يمكنك الاستعلام من جدول واحد فقط. تحتاج إلى ربطها (JOIN):

SELECT
  projects.project_name,
  employees.name AS lead_name
FROM projects
INNER JOIN employees ON projects.lead_employee_id = employees.id;

جملة ON هي المفتاح—إنها التعليمات التي تخبر قاعدة البيانات كيف يرتبط الجدولان. يقوم المحرك بعد ذلك بإنشاء عرض مؤقت ومدمج للبيانات حيث تتطابق المعرفات (IDs)، ويسحب اسم المشروع واسم الموظف منه.

التجميع: GROUP BY والدوال التجميعية

في بعض الأحيان لا تريد صفوفًا فردية؛ بل تريد ملخصات. هنا يأتي دور الدوال التجميعية مثل COUNT(), SUM(), AVG(), MAX(), و MIN(). وعندما تقترن بـ GROUP BY، تصبح قوة خارقة لتحليل البيانات.

هل تريد معرفة عدد الموظفين في كل قسم؟

SELECT
  department,
  COUNT(id) AS number_of_employees
FROM employees
GROUP BY department;

تقوم قاعدة البيانات أولاً بتجميع الصفوف منطقيًا حسب department. بعد ذلك، داخل كل مجموعة، تطبق الدالة COUNT(id). والنتيجة هي جدول ملخص:

department	number_of_employees
Engineering	2
Marketing	1

قاعدة البيانات في متصفحك: SQLite و WebAssembly

إذن كيف يعمل هذا في أداة متصفح بدون خادم؟ السر هو WebAssembly (Wasm). SQLite، أحد أشهر محركات قواعد البيانات في العالم، مكتوب بلغة البرمجة C. باستخدام مترجم خاص (مثل Emscripten)، يمكن ترجمة كود C هذا ليس إلى ملف تنفيذي تقليدي، ولكن إلى وحدة Wasm.

يمكن لمتصفحك تحميل وتشغيل وحدة Wasm هذه في بيئة معزولة وآمنة (sandbox). والنتيجة هي أن لديك محرك قاعدة بيانات SQL كامل، قائم على الملفات، ويدعم المعاملات (transactional) يعمل محليًا. عندما تكتب استعلامًا، لا يتم إرساله عبر الشبكة. يتم تسليمه مباشرة إلى محرك SQLite الموجود في الذاكرة، الذي يعالجه ويعيد النتائج. إنه سريع، ويحافظ على الخصوصية، ولا يتطلب أي إعداد—بيئة مثالية للتعلم والاختبار واستكشاف البيانات السريع.

قصص من الواقع

قضية الـ API الوهمي "السريع وغير المتقن"

كانت مطورة واجهة أمامية (frontend) تبني مكونًا معقدًا لعرض البيانات في شبكة (data grid). لم تكن واجهة برمجة التطبيقات (API) الخلفية جاهزة بعد، لكن كان لديها مخطط JSON للبيانات. كانت بحاجة لاختبار الفرز والتصفية وترقيم الصفحات (pagination). بدلاً من كتابة الكثير من منطق JavaScript الوهمي، قامت بلصق البيانات في أداة SQL قائمة على المتصفح، وأنشأت جدول products على الفور. ثم تمكنت من كتابة استعلامات SQL بسيطة مثل SELECT * FROM products WHERE category = 'Gadgets' ORDER BY price DESC LIMIT 20 OFFSET 40. هذا حاكى تمامًا استدعاءات الـ API الحقيقية، مما سمح لها ببناء واختبار واجهة المستخدم بأكملها قبل حتى أن يتم نشر الواجهة الخلفية.

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

السلاح السري لمحلل البيانات

أُعطي محلل أعمال ثلاثة ملفات CSV منفصلة: واحد للعملاء، وواحد للطلبات، وواحد للمنتجات. أراد رئيسه معرفة "أي العملاء في كاليفورنيا اشتروا أكبر عدد من 'SuperWidget 3000s' الشهر الماضي". كان القيام بذلك في Excel كابوسًا من استخدام VLOOKUP والجداول المحورية (pivot tables) والأوراق المؤقتة. بدلاً من ذلك، قام المحلل بتحميل ملفات CSV الثلاثة في بيئة SQL تجريبية، مما أدى إلى إنشاء ثلاثة جداول. وباستعلام واحد محكم يربط الجداول الثلاثة، ويفلتر حسب الولاية واسم المنتج، ويجمع حسب العميل، حصل على الإجابة في دقائق.

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

مدير قاعدة البيانات بالصدفة

كان مبرمج جديد يقوم بإصلاح مشكلة أداء. كانت إحدى صفحات تطبيقه تستغرق وقتًا طويلاً جدًا للتحميل. نظر إلى الكود ورأى أنه كان يجلب قائمة بجميع المستخدمين، ثم يمر عليهم واحدًا تلو الآخر لإجراء استدعاء آخر لقاعدة البيانات لكل مستخدم للحصول على عدد منشوراته. هذا ما يسمى "مشكلة N+1 query". المطور الأقدم الذي كان يساعده لم يقم بإصلاحها فحسب؛ بل فتح بيئة SQL تجريبية، وأنشأ جدولين بسيطين (users, posts)، وأراه كيف يمكن لاستعلام GROUP BY واحد الحصول على جميع الأعداد دفعة واحدة. وهنا أضاء المصباح في رأسه.

الدرس المستفاد: فهم طريقة تفكير SQL يساعدك على كتابة كود تطبيق أكثر كفاءة عن طريق تفويض مهام البيانات المعقدة إلى قاعدة البيانات، والتي هي مُحسَّنة للغاية للقيام بذلك.

أخطاء وفخاخ شائعة

• SELECT * هو صديقك وعدوك في نفس الوقت. إنه رائع لعمل SELECT * FROM my_table LIMIT 10 سريع لمعرفة ما هي الأعمدة. لكن في كود التطبيق، هو فخ للأداء. فهو يجلب بيانات لا تحتاجها، ويضع ضغطًا أكبر على قاعدة البيانات والشبكة، ويمكن أن يتسبب في تعطل تطبيقك إذا قام شخص ما بإضافة أو إزالة أو إعادة تسمية عمود في الجدول. كن صريحًا بشأن الأعمدة التي تحتاجها.
• نسيان WHERE عند UPDATE أو DELETE. هذا هو طقس العبور النهائي لأي شخص يعمل مع SQL. DELETE FROM users; لا يحذف مستخدمًا واحدًا. إنه يحذف جميع المستخدمين. جملة WHERE هي حزام الأمان الذي يمنعك من مسح بياناتك. تحقق دائمًا مرتين من جملة WHERE الخاصة بك في أي عبارة لتعديل البيانات.
• NULL ليست صفرًا أو سلسلة نصية فارغة. NULL تمثل غياب القيمة، ولها منطق غريب ثلاثي القيم. مقارنة مثل my_column = NULL لن تعمل كما تتوقع. يجب عليك استخدام my_column IS NULL أو my_column IS NOT NULL. هذا الفخ يقع فيه كل مبتدئ تقريبًا.
• الخلط بين WHERE و HAVING. كلاهما يقومان بالفلترة، ولكن في مراحل مختلفة. WHERE تفلتر الصفوف قبل أن يتم تجميعها بواسطة GROUP BY. HAVING تفلتر المجموعات بعد أن يتم إنشاؤها وتجميعها. إذا كنت تريد الفلترة بناءً على دالة تجميعية (مثل COUNT(*) > 5)، فيجب أن تكون في جملة HAVING.

لماذا يجب أن تكون على رادارك

SQL ليست فقط لمديري قواعد البيانات. في عالم اليوم القائم على البيانات، هي مهارة أساسية لمجموعة هائلة من الأدوار:

• مطورو الواجهات الخلفية (Backend) يحتاجونها لبناء واجهات برمجة التطبيقات (APIs) وإدارة بيانات التطبيق.
• مطورو الواجهات الأمامية (Frontend) يستفيدون من فهمها للتفاعل مع APIs بشكل أكثر فعالية وبناء تجارب مستخدم أفضل.
• علماء ومحللو البيانات يعيشون ويتنفسون SQL. إنها الطريقة الأساسية التي يستخرجون بها البيانات الأولية ويستكشفونها.
• مديرو المنتجات يمكنهم استخدامها للإجابة على أسئلتهم الخاصة حول سلوك المستخدم دون الحاجة إلى انتظار تذكرة من فريق الهندسة.

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

تعمق أكثر

• Wikipedia: SQL: نظرة عامة عالية المستوى على تاريخها ومعاييرها وتنوعاتها.
• SQLite: SQL Understood by SQLite: الوثائق الرسمية للهجة SQL المحددة التي يستخدمها محرك SQLite، والذي يدعم العديد من الأدوات داخل المتصفح.
• SQLBolt: مجموعة ممتازة وتفاعلية من الدروس لتعلم SQL من الألف إلى الياء.
• PostgreSQL Tutorial: مورد رائع لتعلم لهجة SQL أكثر ثراءً بالميزات وتعتمد على الخوادم.
• A Relational Model of Data for Large Shared Data Banks: الورقة البحثية الأصلية لعام 1970 بقلم إي. إف. كود التي بدأت كل شيء. قراءة كثيفة ولكنها ذات أهمية تاريخية.
• Select Star SQL: كتاب ممتع ومرئي وتفاعلي يعلم SQL بأسلوب ودود.

كيف يفهم المحرر الشيفرة

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

CodeMirror & Lezer: MIT.