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

Question

كنت أجري مناقشة مع مطور في العمل حول مسألة يجب أن يستخدم الجدول القيم الافتراضية. هل هناك قاعدة صعبة وسريعة في هذا أو هل هي منطقة رمادية في أفضل الممارسات؟

Answer 1

قاعدتي: إذا كانت العديد من السجلات ستستخدم هذا الافتراضي (على الأقل في البداية) ، فأنا أحب استخدامه كإعداد افتراضي. على سبيل المثال ، قد يكون لجدول صورة للمنتجات في متجر عبر الإنترنت مسار افتراضي images/NoPictureYet.png. في نهاية المطاف ، سيتم استبدال هؤلاء ، ولكن بالنسبة للكمال الدُفعات من البيانات حيث لا توجد الصور ببساطة بعد (وربما معظمها لن يفعلوا ذلك أبدًا!) ، فإن الافتراضي منطقي (بالنسبة لي ، على الأقل).

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

ولكن لا توجد قواعد صعبة وسريعة على هذا. كل شيء يختلف قليلا ؛)

Answer 2

إحدى الحالات العملية حيث وجدت شخصياً الاستخدام الجيد للقيم الافتراضية هو ل last_modified عمودي.

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

ALTER TABLE users ADD CONSTRAINT dc_users_last_modified
                  DEFAULT GETDATE()
                  FOR last_modified;

سيبدو مشغل التحديث مثل شيء مثل هذا:

CREATE TRIGGER trigUpdate_users 
ON users 
FOR UPDATE 
AS 
BEGIN 
    IF NOT UPDATE(last_modified) 
        UPDATE users SET last_modified = GETDATE() 
        WHERE user_id IN (SELECT user_id FROM inserted);
END 
GO

Answer 3

لا يمكن تطبيق قاعدة صعبة وسريعة. ذلك يعتمد على الأعمدة. قد يكون من المعقول تمامًا أن يكون لديك نوع طلب افتراضي ، على سبيل المثال ، لكن فكرة الافتراضي لرقم هاتف العميل لا معنى له.

Answer 4

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

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

Answer 5

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

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

ثم هناك أعمدة يتم إعطاؤها عادةً قيمة على إدخال البيانات قد تتغير لاحقًا. أشياء مثل عمود الحالة.

العديد من الأعمدة لا يمكن أن يكون لها بالفعل افتراضي. ماذا سيكون العنوان الافتراضي أو اسم المستخدم؟

Answer 6

TL ؛ DR: القيم الافتراضية هي منطق الأعمال ، وأريد منطق العمل في نموذج الكائن. على هذا النحو ، لا يمكن أن تحتوي قاعدة البيانات على قيم افتراضية.

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

إخلاء المسئولية: أعيش في عالم OO واستخدم LINQ2SQL.

Answer 7

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

Answer 8

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

1) CreatedDate و ModifiedDate Columns. عادةً ما تكون هذه الأعمدة قد تم تعريف GetDate () (SQL Server) على أنها الافتراضي. كما هو مذكور في المنشورات الأخرى ، يمكن بعد ذلك تحديث هذه الحقول بمشغلات وما إلى ذلك.

2) أعمدة الحالة المنطقية. أمثلة: "isDefault" ، "isdeleted" (للمراجعة) ، "Isactive" ، إلخ. سيكون لكل هذه الحقول عمومًا حالة افتراضية منطقية يجب تحديدها بواسطة نموذج البيانات. من الواضح أن الاستثناءات من هذا الأمر قد تكون حقول Boolean Boolean Nullable حيث تمثل الحالة الفارغة شيئًا عن البيانات المخزنة في السجل.

3) تعريفات قيود البيانات: أعمدة مع AllowOwnl = false ولم يتم تحديد الافتراضي. بمعنى آخر ، هناك حاجة إلى قيمة من قبل التطبيق.

4) جدول البحث الهويات الخارجية: ربما لا يكون هذا هو القاعدة ولكن بالنسبة للكثير من المفاتيح الخارجية لجدول البحث ، سأحدد افتراضيًا يغطي الحالة الأولية للسجل. لذلك على سبيل المثال ، في جدول "حدث" ، سيكون للعمود المفتاح الخارجي "EventTypeid" (int-autoincrement) افتراضيًا 1 ويمثل "عام" أو شيء من هذا القبيل. سيغطي هذا معظم السيناريوهات حيث ، على سبيل المثال ، أريد تسجيل حدث ولكن لا أهتم بمعرف نوع معين.

5) أعمدة السلسلة غير الحرجة: "الوصف" ، "التعليق" وما إلى ذلك بالنسبة لهذه الأعمدة ، سأعرّف عمومًا "" الافتراضي "ل simpify system.dbnull => معالجة التحويل الفارغة في التطبيقات. هذا شيء قد لا يكون قابلاً للتطبيق في جميع السيناريوهات خاصة عندما يحتوي الجدول المعني على ملايين الصفوف ومساحة التخزين يمثل مشكلة.

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

Answer 9

بالتأكيد منطقة رمادية. إنه كلاسيكي من كمية منطق العمل الذي يجب وضعه في سؤال قاعدة البيانات.

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

نكون عملياً ، يمكننا أن نجعل استثناءًا كما نفعل في كثير من الأحيان والسماح بمنطق الافتراضي في قاعدة البيانات.