تعرّف على العناصر المضادة وخطط التنفيذ وتعقيد الوقت وضبط الاستعلام وتحسين SQL
لغة الاستعلامات المركبة (SQL) هي مهارة لا غنى عنها في صناعة علوم الكمبيوتر ، وبشكل عام ، تعلم هذه المهارة بسيط نسبيًا. ومع ذلك ، ينسى معظم الناس أن لغة SQL لا تتعلق فقط بكتابة الاستعلامات ، بل إنها مجرد خطوة أولى في الطريق. ضمان أداء الاستعلام أو مطابقة السياق الذي تعمل فيه شيء مختلف تمامًا.
هذا هو السبب في أن دليل SQL هذا سوف يوفر لك نظرة عامة بسيطة على بعض الخطوات التي يمكنك من خلالها تقييم استعلامك:
- أولاً ، ستبدأ بإلقاء نظرة عامة مختصرة على أهمية تعلم SQL للعمل في مجال علم البيانات ؛
- بعد ذلك ، سوف تتعلم أولاً كيفية معالجة وتنفيذ استعلامات SQL لفهم أهمية إنشاء استعلامات الجودة. وبشكل أكثر تحديدًا ، سترى أن الطلب قد تم تحليله وإعادة كتابته وتحسينه وتقييمه أخيرًا.
- مع وضع ذلك في الاعتبار ، لن تذهب فقط إلى بعض مضادات الاستعلامات التي يقوم بها المبتدئين عند كتابة الاستعلامات ، ولكن أيضًا معرفة المزيد حول بدائل وحلول هذه الأخطاء المحتملة ؛ بالإضافة إلى ذلك ، سوف تتعلم المزيد عن نهج الاستعلام المستند إلى مجموعة.
- سترى أيضًا أن هذه الأضداد تنبع من مشاكل الأداء وأنه بالإضافة إلى النهج "اليدوي" لتحسين استعلامات SQL ، يمكنك تحليل استفساراتك بطريقة أكثر تنظيماً وتعمقًا ، باستخدام بعض الأدوات الأخرى التي تساعدك على رؤية خطة الاستعلام ؛ و،
- سوف تتعلم باختصار مدى تعقيد الوقت وترميز O الكبير ، للتعرف على مدى تعقيد خطة التنفيذ في الوقت المناسب قبل تنفيذ الطلب ؛
- ستتعلم لفترة وجيزة كيفية تحسين استفسارك.
لماذا يجب أن تتعلم SQL للعمل مع البيانات؟
تعد SQL بعيدة عن أن تكون ميتة: هذه واحدة من أكثر المهارات المطلوبة التي تجدها في توصيف الوظائف من صناعة معالجة البيانات وتحليلها ، بغض النظر عما إذا كنت تتقدم بطلب لتحليل البيانات أو مهندس البيانات أو أخصائي البيانات أو أي أدوار أخرى. تم تأكيد ذلك من قِبل 70٪ من المجيبين على استبيان راتب O Reilly Data Science لعام 2016 ، والذين يشيرون إلى أنهم يستخدمون SQL في سياقهم المهني. علاوة على ذلك ، في هذا الاستطلاع ، تميز SQL أعلى لغات البرمجة R (57٪) و Python (54٪).
يمكنك الحصول على الصورة: SQL هي مهارة ضرورية عندما تعمل على الحصول على وظيفة في صناعة تكنولوجيا المعلومات.
ليس سيئا للغة التي تم تطويرها في أوائل السبعينات ، أليس كذلك؟
ولكن لماذا يتم استخدامه في كثير من الأحيان؟ ولماذا لم يمت ، على الرغم من وجوده لفترة طويلة؟
هناك عدة أسباب: قد يكون أحد الأسباب الأولى أن الشركات تقوم بشكل رئيسي بتخزين البيانات في أنظمة إدارة قواعد البيانات العلائقية (RDBMS) أو في أنظمة إدارة تدفق البيانات العلائقية (RDSMS) ، ويطلب من SQL الوصول إلى هذه البيانات. SQL هي
اللغة المشتركة للبيانات: فهي تتيح التفاعل مع أي قاعدة بيانات تقريبًا أو حتى بناء قاعدة بيانات خاصة بك محليًا!
إذا كان هذا لا يزال غير كافٍ ، فضع في اعتبارك أن هناك عدد قليل من تطبيقات SQL غير متوافقة بين البائعين ولا تتوافق بالضرورة مع المعايير. لذلك ، تعد معرفة لغة SQL القياسية أمرًا ضروريًا لك لإيجاد طريقك في الصناعة (علوم الكمبيوتر).
بالإضافة إلى ذلك ، من الآمن القول أن التقنيات الحديثة قد انضمت أيضًا إلى SQL ، مثل Hive ، وهي واجهة لغة استعلام شبيهة بـ SQL لاستعلام مجموعات البيانات الكبيرة وإدارتها ، أو Spark SQL ، والتي يمكن استخدامها لتنفيذ استعلامات SQL. مرة أخرى ، فإن SQL تجد أن هناك مختلفة عن المعيار الذي يمكن أن تتعلم ، ولكن منحنى التعلم سيكون أبسط بكثير.
إذا كنت ترغب في إجراء مقارنة ، فاعتبرها بمثابة تعلم الجبر الخطي: بعد وضع كل هذه الجهود في هذا الموضوع الأول ، تعلم أنه يمكنك استخدامه لإتقان تعلم الآلة أيضًا!
باختصار ، لهذا السبب يجب أن تتعلم لغة الاستعلام هذه:
- من السهل جدًا التعلم ، حتى للمبتدئين. منحنى التعلم بسيط وتدريجي ، لذا ستكتب الاستعلامات في أسرع وقت ممكن.
- يتبع مبدأ "تعلم مرة واحدة ، استخدم في كل مكان" ، لذلك هذا استثمار كبير في وقتك!
- هذه إضافة رائعة إلى لغات البرمجة ؛ في بعض الحالات ، يكون كتابة استعلام أفضل من كتابة التعليمات البرمجية ، لأنه أكثر كفاءة!
- ...
ماذا لا تزال تنتظر؟ :)
مزود معالجة وتنفيذ الاستعلام
لتحسين أداء استعلام SQL الخاص بك ، عليك أولاً معرفة ما يحدث في الداخل عند النقر فوق اختصار لتنفيذ الاستعلام.
أولاً ، يتم تحليل الطلب في شجرة تحليل ؛ يتم تحليل الطلب للامتثال للمتطلبات النحوية والدلالية. يقوم المحلل اللغوي بإنشاء تمثيل داخلي لطلب الإدخال. ثم يتم نقل هذا الإخراج إلى آلية إعادة الكتابة.
بعد ذلك ، يجب على المُحسِّن العثور على خطة التنفيذ أو الاستعلام المثلى للاستعلام المحدد. تحدد خطة التنفيذ بدقة الخوارزمية المستخدمة في كل عملية ، وكيفية تنسيق العمليات.
للعثور على أفضل خطة تنفيذ ، يسرد المُحسِّن جميع خطط التنفيذ الممكنة ، ويحدد جودة كل خطة أو تكلفتها ، ويتلقى معلومات عن الحالة الحالية لقاعدة البيانات ، ثم يختار الأفضل منها كخطة تنفيذ أخيرة. نظرًا لأن محسِّن الاستعلام يمكن أن يكون غير كامل ، يتعين على المستخدمين ومسؤولي قواعد البيانات في بعض الأحيان فحص الخطط التي تم إنشاؤها بواسطة المُحسّن وضبطها يدويًا لتحسين الأداء.
الآن ربما تتساءل ما الذي يعتبر "خطة استعلام جيدة".
كما قرأت بالفعل ، تلعب جودة تكلفة الخطة دورًا مهمًا. وبشكل أكثر تحديدًا ، تعتبر أشياء مثل رقم القرص I / Os المطلوب لتقييم الخطة ، وتكلفة وحدة المعالجة المركزية للخطة ، ووقت الاستجابة الكلي الذي يمكن أن يلاحظه عميل قاعدة البيانات ، وإجمالي وقت التنفيذ ، مهمة. هذا هو المكان الذي ينشأ فيه مفهوم التعقيد الزمني. سوف تتعلم المزيد عن هذا لاحقًا.
بعد ذلك ، يتم تنفيذ خطة الاستعلام المحددة وتقييمها بواسطة آلية تنفيذ النظام ، ويتم إرجاع نتائج الاستعلام.
كتابة استعلامات SQL
ربما لم يتضح من القسم السابق أن مبدأ Garbage In ، Garbage Out (GIGO) يتجلى بشكل طبيعي في عملية معالجة وتنفيذ استعلام: الشخص الذي يصوغ الاستعلام لديه أيضًا مفاتيح لأداء استعلامات SQL الخاصة بك. إذا كان المحسن يتلقى طلبًا سيئ الصياغة ، فيمكنه فعل الكثير ...
هذا يعني أن هناك بعض الأشياء التي يمكنك القيام بها عند كتابة الطلب. كما رأينا بالفعل في المقدمة ، فإن المسؤولية هنا ذات شقين: لا يتعلق الأمر فقط بكتابة استفسارات تتوافق مع معيار معين ، ولكن أيضًا حول جمع الأفكار حول الأماكن التي قد تكون مشكلات الأداء مخفية فيها في استعلامك.
تتمثل نقطة الانطلاق المثالية في التفكير في "الأماكن" في استفساراتك حيث قد تنشأ مشاكل. وبشكل عام ، هناك أربع كلمات رئيسية يمكن للوافدين الجدد توقع حدوث مشكلات في الأداء:
- حالة
WHERE ؛ - أي كلمات رئيسية
INNER JOIN أو LEFT JOIN ؛ و كذلك HAVING حالة
بالطبع ، هذا النهج بسيط وساذج ، لكن بالنسبة للمبتدئين ، فإن هذه النقاط هي مؤشرات ممتازة ، ومن الآمن أن نقول أنه عند البدء لأول مرة ، تحدث أخطاء في هذه الأماكن ، ومن الغريب أن يكون من الصعب ملاحظتها.
ومع ذلك ، يجب أن تفهم أيضًا أن الأداء شيء يجب أن يصبح ذا معنى. ومع ذلك ، فإن مجرد قول أن هذه الجمل والكلمات الرئيسية سيئة ليست ما تحتاجه عند التفكير في أداء SQL. لا يعني وجود
WHERE أو
HAVING في الطلب بالضرورة أنه طلب سيئ ...
تحقق من القسم التالي لمعرفة المزيد عن مضادات الأوجه والأساليب البديلة لإنشاء استفسارك. وتهدف هذه النصائح والحيل كدليل. كيف إذا كنت تحتاج حقًا إلى إعادة كتابة طلبك ، يعتمد ، من بين أشياء أخرى ، على مقدار البيانات وقاعدة البيانات وعدد المرات التي تحتاجها لإكمال الطلب. ذلك يعتمد كليا على الغرض من طلبك والحصول على بعض المعرفة المسبقة حول قاعدة البيانات التي ستعمل بها أمر بالغ الأهمية!
1. استرداد فقط البيانات اللازمة
الاستنتاج "كلما زادت البيانات ، كلما كان ذلك أفضل" - لا يجب اتباعه عند كتابة SQL: أنت تخاطر ليس فقط بالارتباك من خلال الحصول على بيانات أكثر مما تحتاجه بالفعل ، ولكن قد يتأثر الأداء أيضًا لأن استعلامك يتلقى الكثير من البيانات.
لهذا السبب ، كقاعدة عامة ، يجب الانتباه إلى
SELECT DISTINCT وبيان
LIKE .
SELECT
أول شيء يمكنك التحقق منه بالفعل عند كتابة استعلام هو ما إذا كانت
SELECT مضغوطة قدر الإمكان. يجب أن يكون الهدف هنا إزالة الأعمدة غير الضرورية من
SELECT . بهذه الطريقة تجبر نفسك على استرداد البيانات التي تخدم غرض الاستعلام فقط.
إذا كنت قد ربطت استعلامات فرعية مع
EXISTS ، فيجب أن تحاول استخدام ثابت في
SELECT لهذا الاستعلام الفرعي بدلاً من اختيار قيمة العمود الفعلي. هذا مناسب بشكل خاص عند التحقق من وجوده فقط.
تذكر أن استعلام فرعي مرتبط هو استعلام فرعي يستخدم قيمًا من استعلام خارجي. ولاحظ أنه على الرغم من أن
NULL يمكن أن تعمل "ثابتًا" في هذا السياق ، إلا أن هذا أمر محير للغاية!
خذ بعين الاعتبار المثال التالي لفهم المقصود باستخدام ثابت:
SELECT driverslicensenr, name FROM Drivers WHERE EXISTS (SELECT '1' FROM Fines WHERE fines.driverslicensenr = drivers.driverslicensenr);
نصيحة: من المفيد معرفة أن وجود استعلام فرعي مرتبط ليس دائمًا فكرة جيدة. يمكنك دائمًا التفكير في التخلص منها ، على سبيل المثال ، من خلال إعادة كتابتها باستخدام
INNER JOIN :
SELECT driverslicensenr, name FROM drivers INNER JOIN fines ON fines.driverslicensenr = drivers.driverslicensenr;
عملية مميزة
يتم استخدام
SELECT DISTINCT لإرجاع قيم مختلفة فقط.
DISTINCT هو نقطة يجب بالتأكيد تجنبها إن أمكن. كما في الأمثلة الأخرى ، يزيد وقت التنفيذ فقط عند إضافة هذه الجملة إلى الطلب. لذلك ، من المفيد دائمًا التفكير فيما إذا كنت تحتاج حقًا إلى هذه العملية المميزة للحصول على النتائج التي تريد تحقيقها.
LIKE بيان
عند استخدام عامل التشغيل
LIKE في استعلام ، لا يتم استخدام الفهرس إذا كان النموذج يبدأ بـ
% أو
_ . سيمنع هذا قاعدة البيانات من استخدام الفهرس (في حالة وجودها). بالطبع ، من وجهة نظر أخرى ، يمكن القول أيضًا أن هذا النوع من الطلبات قد يترك إمكانية الحصول على الكثير من السجلات التي لا تفي بالضرورة بالغرض من الطلب.
مرة أخرى ، يمكن أن تساعدك معرفة البيانات المخزنة في قاعدة البيانات على صياغة قالب يقوم بتصفية جميع البيانات بشكل صحيح للعثور على الصفوف التي تعتبر مهمة بالفعل لاستعلامك.
2. الحد من النتائج الخاصة بك
إذا لم تتمكن من تجنب تصفية
SELECT الخاص بك ، يمكنك تقييد نتائجك بطرق أخرى. هذا هو المكان الذي تأتي منه مقاربات مثل
LIMIT وتحويلات نوع البيانات.
ROWNUM TOP و LIMIT و ROWNUM
يمكنك إضافة عبارات
LIMIT أو
TOP إلى الاستعلامات لتحديد الحد الأقصى لعدد الصفوف لمجموعة النتائج. فيما يلي بعض الأمثلة:
SELECT TOP 3 * FROM Drivers;
لاحظ أنه يمكنك تحديد
PERCENT اختياريًا ، على سبيل المثال ، إذا قمت بتغيير سطر الاستعلام الأول باستخدام
SELECT TOP 50 PERCENT * .
SELECT driverslicensenr, name FROM Drivers LIMIT 2;
بدلاً من ذلك ، يمكنك إضافة
ROWNUM مكافئة لاستخدام
LIMIT في الاستعلام:
SELECT * FROM Drivers WHERE driverslicensenr = 123456 AND ROWNUM <= 3;
تحويلات نوع البيانات
الأكثر فاعلية يجب استخدامها دائمًا ، أي أصغر أنواع البيانات. هناك دائمًا خطر عندما تقدم نوعًا كبيرًا من البيانات ، في حين أن النوع الأصغر سيكون أكثر كفاية.
ومع ذلك ، عند إضافة تحويل نوع بيانات إلى الاستعلام ، يزيد وقت التنفيذ فقط.
البديل هو تجنب تحويل نوع البيانات قدر الإمكان. يرجى أيضًا ملاحظة أنه لا يمكن دائمًا إزالة أو تخطي تحويل نوع البيانات من الاستعلامات ، ولكن يجب عليك دائمًا السعي لإدراجها ، ويجب عليك التحقق من تأثير الإضافة قبل تنفيذ الاستعلام.
3. لا تجعل الاستفسارات أكثر تعقيدا مما ينبغي
تقودك تحويلات نوع البيانات إلى النقطة التالية: يجب ألا تصمم استفساراتك بشكل مفرط. حاول أن تجعلها بسيطة وفعالة. قد يبدو هذا بسيطًا جدًا أو غبيًا حتى لا يكون تلميحًا ، وذلك لأن الطلبات قد تكون معقدة.
ومع ذلك ، في الأمثلة المذكورة في الأقسام التالية ، سترى أنه يمكنك بسهولة البدء في جعل الاستعلامات البسيطة أكثر تعقيدًا مما ينبغي.
OR المشغل
عند استخدام عامل التشغيل
OR في الاستعلام الخاص بك ، فعلى الأرجح أنك لا تستخدم فهرسًا.
تذكر أن الفهرس هو بنية بيانات تعمل على تحسين سرعة البحث عن البيانات في جدول قاعدة البيانات ، لكنها مكلفة: ستكون هناك حاجة إلى سجلات إضافية وستكون هناك حاجة إلى مساحة تخزين إضافية للحفاظ على بنية بيانات الفهرس. تستخدم الفهارس للبحث أو البحث عن البيانات بسرعة دون الحاجة إلى البحث في كل صف في قاعدة البيانات في كل مرة يتم الوصول إلى جدول قاعدة البيانات. يمكن إنشاء فهارس باستخدام عمود واحد أو أكثر في جدول قاعدة البيانات.
إذا كنت لا تستخدم الفهارس المضمنة في قاعدة البيانات ، فإن تنفيذ استعلامك سيستغرق حتماً وقتًا أطول. هذا هو السبب في أنه من الأفضل البحث عن بدائل لاستخدام عامل التشغيل
OR في الاستعلام الخاص بك ؛
النظر في الاستعلام التالي:
SELECT driverslicensenr, name FROM Drivers WHERE driverslicensenr = 123456 OR driverslicensenr = 678910 OR driverslicensenr = 345678;
يمكن استبدال المشغل بـ:
حالة مع
IN ؛ أو
SELECT driverslicensenr, name FROM Drivers WHERE driverslicensenr IN (123456, 678910, 345678);
SELECT مع
UNION .
نصيحة: هنا يجب أن تكون حريصًا على عدم استخدام عملية
UNION غير الضرورية ، لأنك تعرض نفس الجدول عدة مرات. في نفس الوقت ، يجب أن تفهم أنه عندما تستخدم
UNION في الاستعلام الخاص بك ، يزيد وقت التنفيذ. بدائل لعملية
UNION : أعد صياغة الاستعلام بحيث يتم وضع جميع الشروط في
SELECT واحدة ، أو استخدم
OUTER JOIN بدلاً من
UNION .
نصيحة: ضع في اعتبارك أنه على الرغم من أن
OR - والمشغلين الآخرين الذين سيتم ذكرهم في الأقسام التالية - على الأرجح لا يستخدمون فهرسًا ، إلا أن البحث في الفهرس لا يُفضل دائمًا!
NOT المشغل
عندما يحتوي استعلامك على عامل تشغيل
NOT ، فمن المحتمل ألا يتم استخدام الفهرس ، كما هو الحال مع عامل التشغيل
OR . سيؤدي ذلك إلى إبطاء طلبك. إذا كنت لا تعرف المقصود هنا ، ففكر في الاستعلام التالي:
SELECT driverslicensenr, name FROM Drivers WHERE NOT (year > 1980);
من المؤكد أن هذا الطلب سيكون أبطأ مما تتوقع ، ويرجع ذلك أساسًا إلى أنه أكثر تعقيدًا مما يمكن أن يكون: في مثل هذه الحالات ، من الأفضل البحث عن بديل. فكّر في استبدال
NOT المقارنة مثل
> أو
<> أو
!> ؛ يمكن بالفعل إعادة المثال المثال أعلاه وتبدو شيء مثل هذا:
SELECT driverslicensenr, name FROM Drivers WHERE year <= 1980;
يبدو بالفعل أفضل ، أليس كذلك؟
AND المشغل
عامل التشغيل
AND هو عامل آخر لا يستخدم فهرسًا ويمكن أن يبطئ استعلامه إذا تم استخدامه بطريقة معقدة للغاية وغير فعالة ، كما في المثال التالي:
SELECT driverslicensenr, name FROM Drivers WHERE year >= 1960 AND year <= 1980;
من الأفضل إعادة كتابة هذا الاستعلام باستخدام عبارة
BETWEEN :
SELECT driverslicensenr, name FROM Drivers WHERE year BETWEEN 1960 AND 1980;
ANY ALL المشغلين
بالإضافة إلى ذلك ، فإن
ANY المشغلين
ANY و
ALL هما المشغلان اللذان يجب عليك توخي الحذر منهما ، لأنه إذا قمت بتضمينهما في استفساراتك ، فلن يتم استخدام الفهرس. تعتبر وظائف التجميع البديلة مثل
MIN أو
MAX مفيدة هنا.
نصيحة: في الحالات التي تستخدم فيها البدائل المقترحة ، يجب أن تدرك أن جميع وظائف التجميع ، مثل
SUM و
AVG و
MIN و
MAX على العديد من الأسطر ، يمكن أن تؤدي إلى استعلام طويل. في مثل هذه الحالات ، يمكنك محاولة تقليل عدد الصفوف المراد معالجتها أو حساب هذه القيم مسبقًا. مرة أخرى ترى أنه من المهم أن تعرف عن البيئة الخاصة بك ، والغرض من طلبك ، ... عندما تقرر أي طلب للاستخدام!
عزل الأعمدة في الظروف
أيضًا ، في الحالات التي يتم فيها استخدام عمود في عملية حسابية أو في دالة عددية ، لا يتم استخدام الفهرس. قد يكون الحل المحتمل هو اختيار عمود معين بحيث لا يعد جزءًا من الحساب أو الوظيفة. النظر في المثال التالي:
SELECT driverslicensenr, name FROM Drivers WHERE year + 10 = 1980;
يبدو مضحكا ، هاه؟ بدلاً من ذلك ، حاول مراجعة الحساب وأعد كتابة الاستعلام كما يلي:
SELECT driverslicensenr, name FROM Drivers WHERE year = 1970;
4. عدم وجود القوة الغاشمة
هذه التلميح الأخير يعني أنه يجب ألا تحاول تقييد الطلب أكثر من اللازم ، حيث قد يؤثر ذلك على أدائه. هذا ينطبق بشكل خاص على الصلات ولعبارة HAVING.
ترتيب الجدول في الصلات
عند الانضمام إلى جدولين ، قد يكون من المهم مراعاة ترتيب الجداول في الصلة. إذا رأيت أن أحد الجداول أكبر بكثير من الآخر ، فقد تحتاج إلى إعادة كتابة الاستعلام بحيث يتم وضع الجدول الأكبر في الصلة.
ظروف الاتصال المفرطة
إذا قمت بإضافة العديد من الشروط إلى اتصالات SQL ، يجب عليك اختيار مسار معين. ومع ذلك ، قد يكون هذا المسار ليس دائمًا أكثر كفاءة.
HAVING حالة
تمت إضافة
HAVING في الأصل إلى SQL لأنه لا يمكن استخدام الكلمة الأساسية
WHERE مع الدالات التجميعية. عادةً ما
HAVING استخدام
HAVING مع
GROUP BY لتقييد مجموعات الصفوف التي تم إرجاعها إلى تلك التي تفي بشروط معينة فقط. ومع ذلك ، إذا تم استخدام هذا الشرط في الاستعلام ، فلن يتم استخدام الفهرس ، والذي ، كما تعلمون بالفعل ، يمكن أن يؤدي إلى حقيقة أن الاستعلام في الواقع لا يعمل بشكل جيد.
إذا كنت تبحث عن بديل ، فحاول استخدام
WHERE .
النظر في الاستعلامات التالية:
SELECT state, COUNT(*) FROM Drivers WHERE state IN ('GA', 'TX') GROUP BY state ORDER BY state
SELECT state, COUNT(*) FROM Drivers GROUP BY state HAVING state IN ('GA', 'TX') ORDER BY state
يستخدم الاستعلام الأول
WHERE للحد من عدد الصفوف التي يجب تلخيصها ، بينما يلخص الاستعلام الثاني جميع الصفوف في الجدول ، ثم يستخدم
HAVING لتجاهل المبالغ المحسوبة. في مثل هذه الحالات ، يكون خيار
WHERE أفضل بشكل واضح لأنك لا تهدر الموارد.
يمكن ملاحظة أن هذا لا يتعلق بتحديد مجموعة النتائج ، ولكن يتعلق بتحديد عدد السجلات الوسيطة في الاستعلام.
تجدر الإشارة إلى أن الفرق بين الشرطين هو أن
WHERE تقدم شرطًا للصفوف الفردية ، في حين أن
HAVING تقدم شرطًا للتجميعات أو نتائج الاختيار ، حيث كانت نتيجة واحدة ، مثل
MIN ،
MAX ،
SUM ، ... تم إنشاؤها من خطوط متعددة.
كما ترى ، فإن طلبات تقييم الجودة والكتابة وإعادة الكتابة ليست مهمة سهلة ، بالنظر إلى أنها يجب أن تكون مثمرة قدر الإمكان ؛ سيكون منع مضادات الظهور والنظر في الخيارات البديلة جزءًا من المسؤولية عند كتابة الاستعلامات التي يجب إجراؤها على قواعد البيانات في بيئة احترافية.
كانت هذه القائمة مجرد لمحة صغيرة عن بعض الأضداد والنصائح التي آمل أن تساعد المبتدئين. إذا كنت ترغب في الحصول على فكرة عما يعتبره المطورون الأقدمون أكثر الأنماط المضادة شيوعًا ، فراجع
هذه المناقشة .
مجموعة تستند إلى النهج الإجرائية لكتابة الاستعلامات
ضمنا مضادات المذكورة أعلاه أنها في الواقع إلى الفرق في النهج القائم على مجموعات وإجراءات لبناء استفساراتك.
النهج الإجرائي للاستعلامات نهج مشابه جدًا للبرمجة: تخبر النظام بما يجب القيام به وكيفية القيام به.
مثال على ذلك هو الشروط المفرطة في الاتصالات أو الحالات عند إساءة استخدام شروط
HAVING ، كما في الأمثلة أعلاه ، حيث يمكنك الاستعلام عن قاعدة بيانات عن طريق تنفيذ وظيفة ثم استدعاء وظيفة أخرى ، أو استخدام المنطق الذي يحتوي على شروط ، حلقات ، وظائف معرفة من قبل المستخدم ( UDF) ، المؤشرات ، ... للحصول على النتيجة النهائية. باستخدام هذا النهج ، ستطلب غالبًا مجموعة فرعية من البيانات ، ثم تطلب مجموعة فرعية أخرى من البيانات ، وما إلى ذلك.
مما لا يثير الدهشة ، غالبًا ما يطلق على هذا الأسلوب استعلام "خطوة بخطوة" أو "سطر بسطر".
طريقة أخرى هي نهج قائم على مجموعة ، حيث يمكنك ببساطة الإشارة إلى ما يجب القيام به. دورك هو تحديد الشروط أو المتطلبات لمجموعة النتائج التي تريد تلقيها من الاستعلام. تترك الطريقة التي يتم بها استرداد البيانات الخاصة بك إلى الآليات الداخلية التي تحدد تنفيذ الاستعلام: يمكنك السماح لمحرك قاعدة البيانات بتحديد أفضل الخوارزميات أو منطق المعالجة لتنفيذ استعلامك.
نظرًا لأن SQL تستند إلى مجموعة ، فليس من المستغرب أن يكون هذا النهج أكثر كفاءة من الإجراء ، ويشرح أيضًا السبب في أنه في بعض الحالات ، يمكن تشغيل SQL بشكل أسرع من التعليمات البرمجية.
المشورة هي طريقة قائمة على الاستفسار ، وهي أيضًا طريقة سيطلب منك معظم أصحاب العمل الرائدين في صناعة تكنولوجيا المعلومات إتقانها! غالبًا ما يكون من الضروري التبديل بين هذين النوعين من الأساليب.
يرجى ملاحظة أنه إذا كنت بحاجة إلى طلب إجرائي ، فيجب عليك إعادة كتابته أو إعادة كتابته.
سيغطي الجزء التالي الخطة والاستعلام الأمثل.