هل يجب أن نستخدم قيود المفتاح الخارجي عند استمرار نماذج المجال؟

Question

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

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

إليكم سؤالي (آمل ألا يكون عامًا جدًا):هل يعتبر تطبيق القيود الأساسية في حالات الأطروحات ممارسة جيدة؟

Answer 1

فرض القيود، ولكن لا تعتمد عليها في منطق الأعمال

• لا عمل المنطق في قاعدة البيانات:وأنا أتفق مع المبدأ.وإذا كان الخاص بك غير SQL رمز العمل تعتمد على قيود قاعدة البيانات للتحقق من اتساق قاعدة البيانات الخاصة بك، فيجب عليك إعادة التفكير في منطق عملك.
• لا حرج في وجود قيود قاعدة البيانات فضلاً عن ذلك لمنطق عملك.خاصةً لأن أشياء مثل التكامل المرجعي مع المفاتيح الخارجية والقيود الفريدة الأخرى من السهل القيام بها ويقوم نظام إدارة قواعد البيانات الديناميكية (RDBMS) بهذه المهمة نيابةً عنك بكفاءة عالية دون الحاجة إلى الكثير من الصيانة.
• هل لن تستخدم المؤشرات على قاعدة البيانات أيضا، لأنه ليس كذلك بحتة المتعلقة بالثبات؟
• قد يستغرق البحث عن الأخطاء البرمجية وإصلاحها بعض الوقت، لكنك لا تستطيع ذلك قطعاً لا ترغب في قضاء المزيد من الوقت في التنظيف أو (الأسوأ من ذلك) فقدان بعض البيانات، فقط لأنك وفرت على نفسك مشكلة كتابة نص من سطر واحد لـ FK.حقًا:هل تحصل على شيء مجاني هنا وترفضه؟
• [تحرير-1]: هل يمكنك ضمان إدارة البيانات الموجودة في قاعدة البيانات الخاصة بك فقط عبر التطبيق الخاص بك؟يبدو دائمًا أن هناك استثناءات، معظمها بواسطة المستخدمين المتميزين، الذين يرتكبون أحيانًا (نادرًا جدًا :-) أخطاء وينفذون بعض عبارات SQL لتنظيف التعليمات البرمجية الخاصة بك، وتحديث الحالات (إلى قيم غير صالحة بسبب الأخطاء المطبعية) وما إلى ذلك.
• [تحرير-2]: مبنى مدفوعة بالمجال النموذج ليس عذرًا لعدم تعيين مسؤول قاعدة بيانات جيد.إن استخدام ORM ليس عذرًا لعدم توظيف مطور قاعدة بيانات جيد.

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

Answer 2

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

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

Answer 3

وأشعر تجاهل أدوات مفيدة حقا (سلامة البيانات على مستوى قاعدة البيانات) من أجل تطوير منهجية نقية هي نتائج عكسية. قواعد بيانات جيدة حقا في هذا النوع من الشيء ... نتركهم يفعلون ذلك.

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

Answer 4

وكنت أعتقد ذلك، ولكن لم يتغير رأيي منذ أن بدأت كتابة الكثير من الأنظمة الموجهة الموارد. عادة، يطلب أكثر بكثير من المعوقات الرئيسية فقط الأجنبية للتحقق من صحة قطعة من البيانات - على سبيل المثال، تذكرة الذي هو في حالة "تعيين" يجب أن يكون صالحا "assigned_to" قيمة، وهلم جرا. كل من هذه القواعد ينبغي أن توضع في روتين التحقق من نوع ما، وعلى الرغم من الناحية النظرية أنه قد لا <م> يضر أن يكون التحقق من صحة إضافي على مستوى قاعدة البيانات، إذا كان يعمل التحقق من الصحة على مستوى التطبيق، والتحقق من أجنبي قيد مفتاح يضيع مجرد دورات. أسوأ من ذلك بكثير، رغم ذلك، كنت قد حصلت الآن منطق حول النموذج الخاص بك البيانات المتكررة في مكانين - رمز التحقق من الصحة، والقيود قاعدة البيانات.

وفكروا بهذه الطريقة: هل تريد نقل أي منطق التطبيقات الأخرى في قاعدة البيانات (على سبيل المثال، عن طريق الإجراءات المخزنة) إذا لم يكن لديك ل؟ إذا لم تكن مجبرا على القيام بذلك عن طريق اعتبارات الأداء، أعتقد أن الإجابة يجب أن تكون عموما "لا".

Answer 5

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

نعم، حسنًا، دائمًا ما تفوز الأغلبية المتواضعة بهذا النوع من النقاش بقوة الأرقام فقط، للأسف.

إذا كنت لا تزال ترغب في خوض هذه المعركة، فقد تسأل خصومك كيف يعتزمون منع أي شخص من استخدام "محرري قواعد البيانات المباشرة" (مثل db2-aid، spufi، ...) وكيف يعتزمون منع أي شخص من إفساد قاعدة البيانات باستخدام مثل هذه الأدوات (التي تتجاوز قيود العمل المبرمجة بحكم التعريف).

Answer 6

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

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

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

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