هل إنشاء "سجل وهمية" لإجبار قاعدة البيانات على إطاعة منطق العمل ، أو فكرة جيدة أو فكرة غبية؟

Question

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

لقد رأيت حتى الآن استخدامه بطريقتين:

• عن طريق إضافة حقل مثل isdummy
• عن طريق إضافة حقل شيء يسمى ObjectType الذي يشير إلى النوع: دمية

حسنًا ، إنه يساعد على ما يجب تحقيقه.

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

لذا فإن السؤال هو:هل من الجيد إنشاء سجلات وهمية للحفاظ على منطق العمل كما هو دون تقديم شكوى DB؟ إذا كانت الإجابة بنعم ، فما هي أفضل ممارسة لمنع المطورين من تخطي وجودهم؟ إذا لم يكن الأمر كذلك ، فماذا تفعل لمنع نفسك من الوقوع في موقف ينتهي به الأمر بخيار فقط لإنشاء سجل وهمية؟

شكرًا!

Answer 1

يعد استخدام السجلات الوهمية أدنى من الحصول على القيود بشكل صحيح.

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

Answer 2

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

أي تعريف أو نموذج جيد سيسمح للتغييرات بسهولة ، دون "التأثير على الكود الحالي".

يجب تنفيذ جميع منطق العمل [الذي يتم تعريفه في قاعدة البيانات] باستخدام قيود ANSI SQL والشيكات والقواعد. (بالطبع ، يتم تقييد هياكل المستوى الأدنى بالفعل عبر المجالات/أنواع البيانات ، وما إلى ذلك ، لكنني لن أقوم بتصنيفها على أنها "قواعد عمل".) أتأكد من أنني لا ينتهي بي الأمر إلى تنفيذ الدمى ، ببساطة عن طريق القيام بذلك.

إذا كان لا يمكن القيام بذلك ، فإن Modeller يفتقر إلى المعرفة والخبرة. أو تم كسر متطلبات المستوى الأعلى مثل التطبيع ، والتي تعرض عقبات أمام تنفيذ القيود التي تعتمد عليها ؛ وهذا يعني أيضا فشل modeller.

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

Answer 3

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

Answer 4

باستخدام الدمى غبية.

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

Answer 5

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

إنها بالتأكيد ليست ممارسة شائعة.

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

Answer 6

أعتقد أن أي موقف لا يمكن تمييزه فيه شيء يمكن تمييزه بسهولة حيث أن "سطوع الأعمال" هو سبب لمحاولة التفكير في طريقة أفضل.

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

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

ذكرت نفسك في سؤالك عن القلق. اذهب مع أمعائك. تخلص من السجلات الوهمية.

Answer 7

يجب أن أذهب مع الشعور المشترك هنا وأجادل ضد السجلات الوهمية.

ما سيحدث هو أن مطور جديد لن يعرف عنهم وليس رمزًا للتعامل معهم ، أو حذف جدول ونسيان إضافة سجل وهمية جديد.

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

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

Answer 8

سيكون الحل الصحيح هو تحديث منطق عملك.

على حد تعبير شرحك الموسع:

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

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

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

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