قيمة فارغة (إس كيو إل)

كانت Null محور الجدل ومصدرًا للنقاش بسبب المنطق المرتبط به ثلاثي القيم (3VL)، والمتطلبات الخاصة لاستخدامه في Join (SQL)، والمعالجة الخاصة التي تتطلبها الوظائف التجميعية ومشغلي تجميع SQL. لخص أستاذ علوم الكمبيوتر رون فان دير ميدن القضايا المختلفة على النحو التالي: «التناقضات في معيار SQL تعني أنه لا يمكن إسناد أي دلالات منطقية بديهية إلى معالجة القيم الخالية في SQL.»[1] على الرغم من تقديم العديد من المقترحات لحل هذه القضايا، إلا أن تعقيد البدائل حال دون اعتمادها على نطاق واسع.

لأن القيمة الفارغة Null ليس قيمة بيانات، بل علامة لقيمة غائبة، فإن استخدام معاملات الحسابية على Null يعطي نتيجة غير معروفة، والتي يتم تمثيلها بواسطة Null.[6] في المثال التالي، ينتج عن ضرب 10 في Null قيمة Null ؛

10 * NULL -- Result is NULL

هذا يمكن أن يؤدي إلى نتائج غير متوقعة. على سبيل المثال، عند إجراء محاولة تقسيم Null على صفر، قد تُرجع الأنظمة الأساسية Null بدلاً من طرح «بيانات متوقع - قسمة على صفر».[6] على الرغم من عدم تحديد هذا السلوك بواسطة معيار ISO SQL ، فإن العديد من بائعي DBMS يعاملون هذه العملية بشكل مشابه. على سبيل المثال، تقوم الأنظمة الأساسية Oracle و PostgreSQL و MySQL Server و Microsoft SQL Server بإرجاع نتيجة خالية لما يلي:

NULL / 0

تؤدي عمليات دمج الحروف String، الشائعة في SQL ، أيضًا إلى قيمة فارغة Null عندما يكون أحد المعاملات Null.[7] يوضح المثال التالي نتيجة لا شيء تم إسترجاعها باستخدام Null في لغة SQL || بمعامل دمج سلسلة الحروف.

'Fish ' || NULL || 'Chips' -- Result is NULL

هذا ليس صحيحا لجميع تطبيقات قاعدة البيانات. في Oracle RDBMS على سبيل المثال NULL وسلسلة الفارغة (empty string) تُعتبران نفس الشيء، وبالتالي 'Fish ' || NULL || 'Chips' النتيجة ستكون 'Fish Chips'.

إن سوء فهم كيفية عمل Null هو سبب عدد كبير من الأخطاء في تعليمات SQL البرمجية، سواء في عبارات SQL القياسية ISO أو في لهجات SQL المحددة التي تدعمها أنظمة إدارة قواعد البيانات في العالم الحقيقي. عادة ما تكون هذه الأخطاء نتيجة الخلط بين Null و 0 (صفر) أو سلسلة الحروف الفارغة (empty string). يتم تعريف Null بواسطة معيار SQL على أنه يختلف عن كل من السلسلة الفارغة والقيمة العددية 0. بينما يشير Null إلى عدم وجود أي قيمة، فإن كلا من السلسلة الفارغة والصفر العددي يمثلان القيم الفعلية.

الخطأ التقليدي هو محاولة استخدام عامل التشغيل يساوي = بالاقتران مع الكلمة الأساسية NULL للعثور على صفوف بها Nulls. وفقًا لمعيار SQL ، يعد هذا تركيبًا غير صالح وسيؤدي إلى رسالة خطأ أو استثناء. لكن معظم عمليات التنفيذ تقبل بناء الجملة وتقيم مثل هذه التعبيرات إلى UNKNOWN. والنتيجة هي أنه لم يتم العثور على صفوف - بغض النظر عما إذا كانت الصفوف ذات القيم الخالية موجودة أم لا. الطريقة المقترحة لاسترداد الصفوف ذات القيم الخالية هي استخدام المسند IS NULL بدلاً من = NULL.

SELECT *
FROM sometable
WHERE num = NULL; -- Should be "WHERE num IS NULL"

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

SELECT *
FROM sometable
WHERE num <> 1; -- Rows where num is NULL will not be returned,
                 -- contrary to many users' expectations.

تنشأ هذه الالتباسات لأن قانون الهوية مقيد في منطق SQL. عند التعامل مع مقارنات المساواة باستخدام القيمة الحرفية NULL أو قيمة الحقيقة غير المعروفة، سترجع SQL دائمًا «غير معروف» كنتيجة للتعبير. هذه علاقة تكافؤ جزئية وتجعل SQL مثالاً على المنطق غير انعكاسي.[8] وبالمثل، غالبًا ما يتم الخلط بين القيم الفارغة والسلاسل الفارغة. ضع في اعتبارك الدالة LENGTH ، التي تُرجع عدد الأحرف في السلسلة. عندما يتم تمرير Null إلى هذه الدالة، ترجع الدالة Null. يمكن أن يؤدي هذا إلى نتائج غير متوقعة، إذا لم يكن المستخدمون على دراية بمنطق 3 قيم. مثال أدناه:

SELECT *
FROM sometable
WHERE LENGTH(string) < 20; -- Rows where string is NULL will not be returned.

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

تطبيق ISO SQL لـ Null هو موضوع نقد ومناقشة ودعوات للتغيير. في النموذج العلائقي لإدارة قواعد البيانات: الإصدار 2، اقترح كود أن تطبيق SQL لـ Null كان معيبًا ويجب استبداله بعلامتين مختلفتين من النوع Null. كانت العلامات التي اقترحها ترمز إلى «مفقود لكن قابل للتطبيق» و «مفقود ولكن غير قابل للتطبيق»، والمعروفين باسم قيم A وقيم I ، على التوالي. توصية Codd ، في حالة قبولها، كانت ستتطلب تنفيذ منطق رباعي القيم في SQL.[5] اقترح آخرون إضافة علامات إضافية من النوع Null إلى توصية كودللإشارة إلى المزيد من الأسباب التي تجعل قيمة البيانات «مفقودة»، مما يزيد من تعقيد نظام منطق SQL. في أوقات مختلفة، تم أيضًا تقديم مقترحات لتنفيذ علامات Null متعددة المعرفة من قبل المستخدم في SQL. نظرًا لتعقيد أنظمة المعالجة الفارغة والمنطقية المطلوبة لدعم علامات Null المتعددة، لم يحظ أي من هذه المقترحات بقبول واسع النطاق.

اقترح كريس ديت وهيو داروين، مؤلفا The Third Manifesto، أن تطبيق SQL Null معيب بطبيعته ويجب إزالته تمامًا،[9] مشيرين إلى التناقضات والعيوب في تنفيذ معالجة SQL Null (خاصة في الوظائف الإجمالية) كدليل على ذلك مفهوم Null بالكامل معيب ويجب إزالته من النموذج العلائقي.[10] صرح آخرون، مثل المؤلف فابيان باسكال، بالاعتقاد بأن «كيفية معالجة حساب الوظيفة للقيم المفقودة لا يحكمها النموذج العلائقي».^{[بحاجة لمصدر]}

نقطة أخرى للصراع بشأن Nulls هي أنها تنتهك نموذج افتراض العالم المغلق (Closed-world assumption) لقواعد البيانات العلائقية من خلال إدخال افتراض العالم المفتوح فيه.[11] ينص افتراض العالم المغلق، من حيث صلته بقواعد البيانات، على أن "كل ما تنص عليه قاعدة البيانات، سواء بشكل صريح أو ضمني، فهو صحيح؛ وكل شيء آخر خاطئ.[12]" تفترض طريقة العرض هذه اكتمال معرفة العالم المُخزّن في قاعدة بيانات. ومع ذلك، تعمل القيم الفارغة في ظل افتراض العالم المفتوح، حيث تعتبر بعض العناصر المُخزنة في قاعدة البيانات غير معروفة، مما يجعل المعرفة المخزنة في قاعدة البيانات عن العالم غير مكتملة.