إلى أي مدى يجب أن أكون ليبراليًا مع الأعمدة NOT NULL؟

Question

أقوم بتصميم مخطط قاعدة بيانات، وأتساءل عن المعايير التي يجب استخدامها لتحديد ما إذا كان يجب أن يكون كل عمود أم لا nullable أم لا.

هل يجب أن أضع علامة على أنها ليست فارغة فقط على تلك الأعمدة تمامًا يجب هل سيتم ملؤها لصف واحد ليكون له أي معنى على الإطلاق في طلبي؟

أم هل يجب أن أضع علامة على جميع الأعمدة التي لا أنوي أن تكون فارغة أبدًا؟

ما هي الآثار المترتبة على أداء الأعداد الصغيرة مقابل الأعداد الكبيرة من الأعمدة غير الفارغة؟

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

هل يمكن لمن لديه معرفة أكثر مني أن يعطيني المعلومات الأساسية؟

Answer 1

وينبغي أن يكون بصراحة، لقد اعتقدت دائما NOT NULL الافتراضي. NULL هي حالة خاصة ونيف، ويجب عليك ان تجعل القضية لأنه كلما استخدامه. بالاضافة الى انه من الاسهل بكثير لتغيير عمود من NOT NULL لقيم الفارغة مما هو عليه لتذهب في الاتجاه الآخر.

Answer 2

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

و"هل أنا فقط احتفالا ب NOT NULL فقط تلك الأعمدة التي على الاطلاق ويجب أن تملأ بها لصف واحد لجعل أي معنى على الإطلاق لطلبي؟"

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

---

تحرير:

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

Answer 3

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

والسماح أشياء عشوائية لتكون فارغة هو، عاجلا أو آجلا، <م> دائما كابوس IME. استخدام NULL بعناية وماما - ويعرف ما يعنيه في المنطق الخاص

وتحرير: يبدو أن هناك فكرة أنني يدافعون عن NO أعمدة فارغة من أي وقت مضى. هذا كلام سخيف. NULL <م> هو مفيد، ولكن فقط حيث من المتوقع له.

وDateOfDeath سبيل المثال لو Dorfier هو مثال جيد. ومن شأن NULL DateOfDeath تشير "لم يحدث حتى الآن". الآن، لا أستطيع إرسال بريد WHERE DateOfDeath IS NULL عرض LivingPersons.

ولكن، ماذا يعني NULL تاريخ الطلب؟ أن لم يكن وضع النظام حتى الآن؟ على الرغم من أن هناك رقما قياسيا في جدول ترتيب؟ ماذا عن عنوان NULL؟ تلك هي الأفكار التي ينبغي أن تمر عبر رأسك قبل السماح NULL تكون قيمة.

عودة إلى DateOfDeath - استعلام الأشخاص WHERE DateOfDeath > '1/1/1999' لن تعود السجلات NULL - على الرغم من أننا نعرف أنها منطقيا <م> يجب أن يموت بعد عام 1999 . هل هذا ما تريده؟ إذا لم يكن كذلك، ثم قمت بتضمين أفضل OR DateOfDeath IS NULL في هذا الاستعلام. إذا سمحت <م> جميع الأعمدة أن تكون فارغة، عليك أن تفكر في أن <م> في كل مرة تكتب استعلام . IME، وهذا هو الكثير من الضرائب العقلية ل10٪ أو نحو ذلك من الأعمدة التي لها في الواقع معنى شرعي عندما يكونون فارغة.

Answer 4

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

Answer 5

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

لدي استثناءان:

1. التواريخ التي قد لا يكون تاريخها معروفًا (على سبيل المثال.مطلق)
2. علاقات المفاتيح الأجنبية الاختيارية (MarriedToPersonId).على الرغم من أنني استخدمت في بعض الأحيان صفوفًا "فارغة" في جدول المفاتيح الخارجية وجعلت العلاقة إلزامية (على سبيل المثال.رمز وصف الوظيفة)

لقد استخدمت أيضًا في بعض الأحيان حقول بت صريحة لـ "غير معروف"/"غير محدد" (على سبيل المثال.JobDescriptionCode وIsEmployeed).

لدي بعض الأسباب الأساسية لذلك:

1. ستتسبب القيم الخالية دائمًا في حدوث مشكلات في الحقول الرقمية.دائماً.دائماً.دائماً.لا يهم مدى حرصك في مرحلة ما، حدد X + Y حيث سيحدث الإجمالي وسيُرجع NULL.
2. يمكن أن تتسبب القيم الخالية بسهولة في حدوث مشكلات في حقول السلسلة، وعادةً ما تعالج الحقول (على سبيل المثال.حدد AddrLine1 + AddrLine2 من العناوين).
3. تعد الحماية من القيم الخالية في طبقة منطق الأعمال مضيعة للجهد...فقط لا تسمح لهم بالدخول إلى قاعدة البيانات ويمكنك حفظ 100 سطر من التعليمات البرمجية.

الإعدادات الافتراضية المفضلة لدي:

• سلاسل -> ""، ويعرف أيضًا باسم سلسلة فارغة
• أرقام -> 0
• التواريخ -> اليوم أو فارغة (راجع الاستثناء رقم 1)
• بت -> خطأ

Answer 6

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

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

• صفوف مكررة
• بالقيم الخالية
• ترتيب الأعمدة من اليسار إلى اليمين
• الأعمدة غير المسماة وأسماء الأعمدة المكررة
• فشل في دعم "=" بشكل صحيح
• المؤشرات
• التكرار العالي

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

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

Bob. ____

أم هل يمتنع المرء فقط عن ملء بطاقة عنوان لبوب حتى يحصل على عنوان فعلي له؟

يحرر:تظهر وسيطة التاريخ في الصفحات 53-55 من قاعدة البيانات في العمق، تحت عنوان القسم "لماذا يتم حظر القيم الخالية."

Answer 7

والحقيقة أنني أميل نحو NOT NULL ما لم أرى سببا غير ذلك -. كما قال شخص آخر، شئنا أم أبينا، NULL هي حالة خاصة غريبة

واحدة من المفضلة في ما يخص NULL هي:

SELECT F1 FROM T WHERE F2 <> 'OK'

... منها (في DB2 على الأقل) لن تتضمن أي الصفوف حيث F2 باطل - لأنه في المصطلحات ذات العلاقة، (NULL <> 'OK') IS NULL. ولكن القصد الخاص هو العودة كافة الصفوف يست موافق. تحتاج إلى خارج أو المسند أو إرسال F2 متميزة عن 'OK' بدلا (والذي هو حالة خاصة الترميز في المقام الأول).

والمنظمة البحرية الدولية، NULL هي مجرد واحدة من الأدوات التي مبرمج، مثل الحساب المؤشر أو الحمولة الزائدة المشغل، الذي يتطلب الكثير من الفن كعلم.

وجو كيلكو يكتب عن هذا في SQL للسمارتيز - في فخ باستخدام NULL في التطبيق هو أن معناها هو، أيضا، غير معروف. ويمكن أن تعني غير معروف، غير مهيأ، ناقصة، لا ينطبق - أو كما في المثال البكم أعلاه، يعني موافق أو غير موافق

Answer 8

شكرا لجميع الإجابات الرائعة يا شباب.لقد منحتني الكثير لأفكر فيه، وساعدتني في تكوين رأيي/إستراتيجيتي الخاصة، والتي تتلخص في ما يلي:

السماح لـ Nulls If-and-Ir-If Null في هذا العمود سيكون لها معنى محدد لتطبيقك.

زوجان من المعاني الشائعة لـ null:

• أي شيء يأتي مباشرة من المستخدم
  • هنا يعني null "لم يدخل المستخدم"
  • بالنسبة لهذه الأعمدة، من الأفضل السماح بالقيم الخالية، أو ستحصل عليها فقط asdasd@asd.com اكتب الإدخال على أي حال.
• المفاتيح الخارجية للعلاقات "0 أو 1".
  • null تعني "لا يوجد صف ذو صلة"
  • لذا اسمح بالقيم الخالية لهذه الأعمدة
  • هذا هو واحد جدلي, ، ولكن هذا هو رأيي.

بشكل عام، إذا لم تتمكن من التفكير في معنى مفيد لـ null في عمود، فيجب أن يكون كذلك NOT NULL.يمكنك دائمًا تغييره إلى nullable لاحقًا.

مثال على نوع الشيء الذي انتهى بي الأمر إليه:

create table SalesOrderLine (
    Id int identity primary key,
    -- a line must have exactly one header:
    IdHeader int not null foreign key references SalesOrderHeader, 
    LineNumber int not null, -- a line must have a line number
    IdItem int not null, -- cannot have null item
    Quantity decimal not null, -- maybe could sell 0, but not null
    UnitPrice decimal not null, -- price can be 0, but not null
    -- a null delivery address means not for delivery:
    IdDeliveryAddress int foreign key references Address, 
    Comment varchar(100), -- null means user skipped it
    Cancelled bit not null default (0) -- true boolean, not three-state!
    Delivered datetime, -- null means not yet delivered
    Logged datetime not null default (GetDate()) -- must be filled out
)

Answer 9

وأنا أميل إلى الاتفاق مع dorfier.

وتكون خطيرة في التطبيق الخاص بك عن التحلي بالمرونة عند تلقي قاعدة بيانات قيم فارغة ومعاملتهم القيم كما فارغة، وتعطي لنفسك الكثير من المرونة للسماح الحصول على NULL في إدخال القيم لم تقم بتحديد.

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

Answer 10

والعصا مع NOT NULL على كل شيء حتى الصرير شخص يعانون من آلام حول هذا الموضوع. ثم إزالته على عمود واحد في وقت واحد، كما مضض وقت ممكن. تجنب بلا قيم في DB الخاص بك بقدر ما تستطيع، لطالما يمكنك.

Answer 11

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

Answer 12

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

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

وأنا شخصيا تسمح بالقيم الفارغة في معظم الحالات.

Answer 13

ما هي الآثار المترتبة على أداء الأعداد الصغيرة مقابل الأعداد الكبيرة من الأعمدة غير الفارغة؟

قد يكون هذا واضحا، ولكن, ، عندما يكون العمود فارغًا، سيتطلب كل سجل وحدة تخزين إضافية واحدة.لذلك أ قليل سيستهلك العمود مساحة تخزينية أكبر بنسبة 100% عندما يكون فارغًا، بينما أ معرف فريد سوف تستهلك مساحة تخزينية أكبر بنسبة 0.8% فقط عندما تكون فارغة.

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

Answer 14

يجب أن يكون استخدام "Not Null" أو "Null" مدفوعًا بشكل أساسي بمتطلبات الثبات الخاصة بك.

وجود قيمة Nullable يعني أن هناك حالتين أو ثلاث حالات (ثلاث حالات بها حقول بت)

على سبيل المثال؛إذا كان لدي حقل صغير يسمى "IsApproved" وتم تعيين القيمة في مرحلة لاحقة من الإدراج.ثم هناك ثلاث حالات:

1. "تمت الموافقة" لم تتم الإجابة عليها
2. تمت الموافقة على "IsApproved".
3. لم تتم الموافقة على "IsApproved".

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

Answer 15

وأي عمود قيم الفارغة يشكل انتهاكا لالنموذج العادي الثالث.

ولكن، هذا ليس جوابا.

وربما هذا هو: هناك نوعان من الأعمدة في قواعد البيانات - تلك التي تمسك <م> هيكل البيانات، وتلك التي تمسك <م> المحتوى البيانات. مفاتيح هيكل، حقول المستخدم enterable هي البيانات. أشياء أخرى - أيضا -. انها مكالمة الحكم

والسخافات هذا الهيكل، الذي يستخدم في الانضمام بنود، هي عادة غير فارغة. الاشياء التي من البيانات عادة قيم الفارغة.

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