شرح SQL: لغة الاستعلام التي تعشق الأناقة

في جملة واحدة

تنسيق SQL هو ممارسة تطبيق قواعد أسلوب متسقة على كود SQL لجعله أسهل على البشر في القراءة، وتصحيح الأخطاء (debugging)، والصيانة.

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

لغة الاستعلامات المهيكلة (SQL) هي ملكة التعامل مع البيانات منذ السبعينيات. صُممت لتتحدث الحواسيب مع قواعد البيانات، وهي تؤدي هذه المهمة ببراعة. لكن ما هي المشكلة؟ محرك قاعدة البيانات لا يهمه على الإطلاق كيف يبدو كود الـ SQL الخاص بك.

بالنسبة للكمبيوتر، هذا الكود:

SELECT u.id, p.profile_url, COUNT(c.id) AS comment_count FROM users u JOIN profiles p ON u.id = p.user_id LEFT JOIN comments c ON u.id = c.user_id WHERE u.signup_date > '2023-01-01' GROUP BY u.id, p.profile_url HAVING COUNT(c.id) > 5 ORDER BY comment_count DESC;

...هو نفسه تمامًا مثل هذا الكود:

select u.id,p.profile_url,count(c.id) as comment_count from users u join profiles p on u.id=p.user_id left join comments c on u.id=c.user_id where u.signup_date>'2023-01-01' group by u.id,p.profile_url having count(c.id)>5 order by comment_count desc;

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

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

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

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

الخطوة 1: التحليل المعجمي (Lexical Analysis) أو ما يعرف بـ Tokenization

أولاً، تقوم أداة التنسيق بمسح النص الخام لجملة SQL وتقسيمه إلى سلسلة من "tokens". الـ token هو أصغر وحدة ذات معنى في اللغة. فكر في الأمر على أنه تقسيم جملة إلى كلمات وعلامات ترقيم فردية.

لاستعلام بسيط مثل SELECT name FROM users;، ستبدو سلسلة الـ tokens كالتالي:

نص الـ Token	نوع الـ Token
SELECT	كلمة مفتاحية
name	معرّف
FROM	كلمة مفتاحية
users	معرّف
;	علامة ترقيم

يقوم المحلل المعجمي (lexer) بتصنيف كل جزء من المدخلات: الكلمات المفتاحية (SELECT، FROM، WHERE)، المعرّفات (أسماء الجداول والأعمدة مثل users، name)، المعاملات (=، +، >)، القيم الحرفية (نصوص مثل 'admin' أو أرقام مثل 42)، وعلامات الترقيم. هذه السلسلة من الـ tokens هي المادة الخام للخطوة التالية.

الخطوة 2: التحليل النحوي (Parsing) وشجرة البنية المجردة (AST)

قائمة الـ tokens هي مجرد تسلسل مسطح. لكي تفهم أداة التنسيق الاستعلام حقًا، تحتاج إلى فهم بنيته النحوية. هنا يأتي دور التحليل النحوي (Parsing). يأخذ المحلل النحوي سلسلة الـ tokens ويبني هيكل بيانات هرمي يسمى شجرة البنية المجردة (Abstract Syntax Tree أو AST).

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

لاستعلامنا البسيط SELECT name FROM users;، قد تبدو الـ AST في شكل مبسط كالتالي:

- جملة_Select
  - جزء_Select
    - عنصر_محدد
      - معرّف: "name"
  - جزء_From
    - جدول: "users"

بالنسبة لاستعلام أكثر تعقيدًا مع جزء WHERE، سيكون لدى الـ AST فرع آخر لـ WhereClause، والذي سيحتوي بدوره على عقد تمثل معامل المقارنة والقيم التي يتم مقارنتها. هذه الشجرة هي "النموذج الذهني" لأداة التنسيق عن استعلامك. لم تعد ترى سلسلة من النصوص؛ بل ترى جملة SELECT بأجزاء ومكونات محددة.

الخطوة 3: إعادة الطباعة المنسقة للشجرة (Pretty-Printing)

هنا يحدث السحر. مع وجود الـ AST، يمكن لأداة التنسيق الآن التجول في الشجرة، عقدة تلو الأخرى، وطباعتها مرة أخرى كسلسلة نصية، ولكن هذه المرة مع تطبيق مجموعة متسقة من القواعد.

لدى "أداة الطباعة المنسقة" قاعدة لكل نوع من العقد في الـ AST:

• عندما ترى عقدة SelectStatement، تعرف أنها يجب أن تبدأ سطرًا جديدًا.
• عندما تواجه token من نوع KEYWORD مثل SELECT، تحدد قاعدة حالته (على سبيل المثال، UPPERCASE أي أحرف كبيرة).
• عندما تدخل FromClause، تعرف أنها يجب أن تطبع FROM على سطر جديد وتضع مسافة بادئة للجزء التالي.
• عندما تجد قائمة من الأعمدة في SelectClause، قد يكون لديها قاعدة لوضع كل عمود على سطر جديد إذا تجاوزت القائمة طولًا معينًا.
• عندما ترى token معامل، تضيف مسافات حوله (= تصبح =).

من خلال اجتياز الـ AST بشكل منهجي وتطبيق هذه القواعد، تقوم أداة التنسيق ببناء الناتج النهائي النظيف. هذا النهج قوي لأنه لا يعتمد على التخمين بناءً على الأنماط النصية. إنه يفهم أن user في FROM users هو اسم جدول، ولكن user داخل 'user_profile.jpg' هو مجرد جزء من سلسلة نصية ويجب عدم المساس به. كما يسمح لأدوات التنسيق بالتعامل مع لهجات SQL المختلفة (مثل PostgreSQL، MySQL، T-SQL)، حيث يمكن تكوين المحلل النحوي لفهم الصيغة والكلمات المفتاحية الفريدة لكل منها.

قصص من الواقع

قضية جلسة تصحيح الأخطاء في منتصف الليل

استيقظت بريا، وهي مهندسة كبيرة، على تنبيه من PagerDuty: "استهلاك وحدة المعالجة المركزية لقاعدة البيانات 99%". سجلت الدخول ووجدت المصدر: استعلام SQL وحشي واحد يعمل في حلقة، يستهلك جميع الموارد. تم إرسال الاستعلام قبل ساعة من قبل مطور مبتدئ. فتحت الملف وغرق قلبها. كان عبارة عن كتلة من 250 سطرًا من كود SQL غير المنسق، مزيج فوضوي من الاستعلامات الفرعية المتداخلة، وجمل case، والعديد من JOINs. كان من المستحيل تتبع المنطق.

قبل حتى محاولة فهمه، نسخت الكتلة النصية بأكملها ولصقتها في أداة تنسيق SQL. على الفور، تم ترويض الوحش. كشف الناتج المنسق، بمسافاته البادئة وفواصل الأسطر الواضحة، عن بنية الاستعلام. وهناك كان، واضحًا وضوح الشمس: JOIN إلى جدول ضخم مع شرط ON مفقود، مما أدى إلى ناتج ديكارتي (Cartesian product) كارثي. أضافت شرط ON الصحيح، وأرسلت الإصلاح، وشاهدت استهلاك وحدة المعالجة المركزية لقاعدة البيانات يعود إلى طبيعته.

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

الاندماج ومزيج الأساليب

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

القائد التقني الجديد، الذي سئم من حروب الأسلوب، طبق قاعدة بسيطة: يجب تمرير كل كود SQL عبر أداة تنسيق آلية كجزء من مسار الـ CI/CD قبل أن يتم دمجه. قام بتكوين أداة التنسيق بدليل أسلوب محايد وأضافها إلى خطافات ما قبل الـ commit (pre-commit hooks). توقفت النقاشات بين عشية وضحاها. أصبحت قاعدة الكود موحدة ببطء. يمكن للمهندسين الآن التركيز على ما يفعله الكود، وليس على ما يبدو عليه.

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

المحلل الذي لم يستطع النسخ واللصق

كان بن، وهو محلل بيانات، بحاجة إلى تشغيل استعلام معقد لإنشاء تقرير مبيعات ربع سنوي. أرسل له مهندس الاستعلام عبر البريد الإلكتروني. ولكن عندما نسخ بن الاستعلام من عميل البريد الإلكتروني الخاص به ولصقه في أداة قاعدة البيانات الخاصة به، كان في حالة من الفوضى. أضاف عميل البريد الإلكتروني حرف > إلى كل سطر، وأدرج فواصل أسطر غريبة، وحول علامات الاقتباس إلى علامات اقتباس ذكية (smart quotes). فشل الاستعلام مع عشرات الأخطاء النحوية.

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

الدرس: أداة التنسيق القوية هي أكثر من مجرد أداة تجميل؛ إنها أداة تنظيف يمكنها إنقاذ الكود الذي تشوهه أنظمة غير واعية بالكود مثل البريد الإلكتروني أو الدردشة.

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

• تجاهل اختلافات اللهجات (dialects). تنسيق استعلام Microsoft T-SQL باستخدام مجموعة قواعد PostgreSQL فكرة سيئة. قد "تصلح" أداة التنسيق TOP 10 بتغييرها إلى LIMIT 10، مما قد يتسبب بعد ذلك في خطأ نحوي على SQL Server. تأكد دائمًا من أن أداة التنسيق الخاصة بك مهيأة للهجة SQL الصحيحة.
• تنسيق الكود الذي يتم إنشاؤه تلقائيًا. كن حذرًا جدًا عند تنسيق SQL الذي يتم بناؤه ديناميكيًا بواسطة برنامج أو ORM (Object-Relational Mapper). قد يعتمد هذا التطبيق على بنية سلسلة نصية محددة جدًا — وغالبًا ما تكون قبيحة. "إصلاح" المسافات البيضاء قد يكسر الكود الذي ينشئه أو يقرأه.
• الجدال حول الأسلوب "المثالي". الفائدة الأساسية من التنسيق هي الاتساق. إضاعة الساعات في الجدال حول ما إذا كانت الكلمات المفتاحية يجب أن تكون بأحرف كبيرة أم صغيرة هو أمر غير مثمر. اختر إعدادًا افتراضيًا معقولًا (مثل دليل أسلوب شائع) ودع الأداة تفرضه.
• الاعتماد على التنسيق لإصلاح المنطق السيئ. يمكن لأداة التنسيق أن تجعل استعلامًا بطيئًا وغير فعال يبدو جميلًا. لكنها لن تجعله سريعًا. التنسيق يجعل المنطق السيئ مرئيًا، لكن لا يزال عليك إصلاح مشاكل الأداء أو الصحة الأساسية.

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

إذا كنت تعمل مع البيانات، فأنت تعمل مع SQL. وإذا كنت تعمل مع SQL بأي صفة مهنية، فيجب أن تهتم بقابليته للقراءة. يجب أن تفكر في تنسيق SQL كلما:

• كتبت استعلامًا جديدًا: قم بتنسيقه قبل أن ترسله (commit). إنها هدية لزملائك.
• راجعت كود شخص آخر: إذا كان من الصعب قراءة استعلام ما، يجب أن يكون طلبك الأول هو، "هل يمكنك من فضلك تمرير هذا عبر أداة التنسيق؟"
• صححت خطأ في استعلام معقد: لا تحاول حتى قراءة الكود الخام. قم بتنسيقه أولاً.
• انضممت إلى مشروع جديد: ابحث عن دليل أسلوب SQL الخاص بهم أو تكوين أداة التنسيق. إنها طريقة سريعة لتعلم معايير الفريق.
• أنشأت مشروعًا جديدًا: ضع معيارًا للتنسيق منذ اليوم الأول وقم بأتمتته في مسار الـ CI/CD الخاص بك.

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

تعمق أكثر

• Wikipedia: SQL: نظرة عامة عالية المستوى على اللغة نفسها.
• dbt Labs SQL Style Guide: دليل أسلوب عملي يحظى باحترام واسع لكتابة SQL في فرق البيانات الحديثة.
• SQLFluff Docs: وثائق أداة تدقيق وتنسيق SQL شهيرة وقابلة للتكوين بدرجة عالية. قسم "القواعد" (Rules) فيها هو جولة رائعة في كل الأشياء التي يمكن للمرء تكوينها.
• PostgreSQL: Lexical Structure: غوص عميق في القواعد النحوية الرسمية وقواعد تقسيم الـ tokens (tokenization) لواحدة من أشهر لهجات SQL.