it-swarm.asia

ما هي الحجج ضد أو لوضع منطق التطبيق في طبقة قاعدة البيانات؟

[~ # ~] ملاحظة [~ # ~] يختلف جمهور programmers.se و dba.se ، ولديهما وجهات نظر مختلفة ، لذلك في هذا المثال أعتقد أنه من الصحيح تكرار ما هي الحجج ضد أو لوضع منطق التطبيق في طبقة قاعدة البيانات؟ على programmers.se.

لم أجد مناقشة حول dba على هذا بالفعل ، والمنشور الأصلي يقول كل شيء ، لذلك:

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

أنا شخصياً أفضل الاحتفاظ بأكبر قدر ممكن في طبقة التطبيق لتسهيل التصحيح والاحتفاظ بمسؤوليات الطبقات بشكل منفصل.

ما هي أفكارك حول هذا ، وما الذي يجب أو لا ينبغي تنفيذه في طبقة قاعدة البيانات؟

ملحوظة أنا لست OP لهذا السؤال ، ولكن تركت الصياغة الأصلية سليمة.

74
Phil Lello

أفكار متنوعة ...

سيتجاوز رمز قاعدة البيانات الخاصة بك تقنية عميل التطبيق الخاص بك. فكر في ADO.NET -> Linq -> EF وكذلك ORMs المتنوعة. في حين أنه لا يزال بإمكانك تشغيل رمز SQL Server 2000 من آخر الألفية مقابل جميع تقنيات العميل المذكورة أعلاه.

لديك أيضًا مشكلة العميل المتعددة: لدي .net ، Java و Excel. هذه 3 مجموعات من منطق التطبيق.

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

لا يتغير منطق التطبيق لأحجام البيانات العالية. لدينا 50 ألف صف في الثانية باستخدام procs المخزنة. لا يمكن لفريق شقيق يستخدم الإسبات الحصول على واحد في الثانية

56
gbn

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

آخر 500 عمل عملت بها كان لها تطبيقات مكتوبة في 25 لغة على الأقل تصل إلى OLTP. انتقلت بعض هذه البرامج إلى الإنتاج في السبعينيات.

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

ما هي احتمالات؟

أليس هذا هو أكبر " لا تكرر نفسك " على هذا الكوكب؟

40
Mike Sherrill 'Cat Recall'

أنا أقوم بنقل إجابتي القديمة عبر لم يتم تحريرها من المبرمجين.se ، حيث تبدو الإجابات مستقطبة جدًا بين المواقع.

أعلم أنني في عالم من الأذى هنا ، ولكن ضع منطق الأعمال في قاعدة البيانات للأسباب التالية:

  • يمكنك السماح لمستخدمي الأعمال القوية بالوصول المباشر إلى قاعدة البيانات ولا تقلق بشأن شطبها (أو تقلق أقل مما تفعل مع المنطق القائم على التطبيق)
  • يمكن للمستخدم القوي إنشاء تقارير جديدة دون انتظار إصدار برنامج جديد.
  • يمكنك اختبار SP/TRIGGER code في نسخة من قاعدة البيانات ، تمامًا مثل اختبار المنطق القائم على التطبيق
  • يمكنك الاحتفاظ بـ SQL لإنشاء ملفات sp والمشغلات في الملفات النصية (يجب أن تفعل ذلك على أي حال لرمز الجدول/العرض)
  • يمكنك مزج ومطابقة اللغات دون نقل منطق الأعمال
  • يمكنك إجراء تغييرات على منطق الأعمال دون ترقية كل جزء من البرامج
  • يتغير هيكل التدقيق الخاص بك بنفس الطريقة التي تقوم بها بتدقيق نشاط قاعدة البيانات - عبر التسجيل
  • أمان محسن للغاية والتحكم في الوصول الدقيق (تستخدم معظم تطبيقات المنطق المستندة إلى التطبيق نموذج الأمان الخاص بها ، لذا فإن اختراق البيانات أسهل بكثير. تشفير كلمة المرور القابل للعكس ليس غير شائع)
  • أمان المستخدم من جانب قاعدة البيانات يقلل بشكل كبير من الضرر/السرقة التي يمكن أن تقوم بها SQL

السلبيات هي: - تهديد المطورين عندما يصبح المستخدمون أقل اعتمادًا على مطوري التقارير المخصصة - يحتاج المطورون إلى تعلم لغة برمجة أخرى

لا يجب أن يهم أي من هذين المطورين المهرة.

من المثير للاهتمام ملاحظة أن معظم الإجابات تتحدث من حيث "منطق التطبيق" ، وليس "منطق الأعمال" ، كما لو أن البرنامج ليس هناك لتوفير وظيفة عمل.

29
Phil Lello

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

23
Jack says try topanswers.xyz

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

...
3. أضف قيود التكامل/التحقق إلى قاعدة البيانات الأساسية ، باستخدام رمز أكثر تعقيدًا تم تنفيذه بلغة الإجراء المخزنة في قاعدة البيانات. من هذا ، نحصل على موقع مركزي واحد ونحافظ على التنفيذ المطلق للقواعد حتى بالنسبة للتطبيقات التي لا نعرف عنها! نحصل على لغة واحدة للتعبير عن قواعد العمل في جميع أنحاء مجموعة التطبيقات ودورة الحياة بأكملها ، نظرًا لأن لغة du jour تتغير كثيرًا أكثر من قاعدة البيانات. وهو يعمل على نظام مهم بالفعل كأهم التطبيقات. يتم التعامل مع الأخطاء من خلال التعليمات البرمجية الموجودة التي تعالج أخطاء قاعدة البيانات في تلك التطبيقات. لا يزال هناك خطر أن ينكسر تطبيق ما بالطبع ، ولكن من بين السيناريوهات الثلاثة ، هذا هو الأقل ، والتطبيق المعطل فقط يحتاج إلى أي تعديل ، وليس جميعها (ومعظم آليات SP/قاعدة البيانات ستسمح بالاستثناء تطبيق واحد إذا كان ذلك ضروريًا حقًا). هل تعتقد أن هذا لا يهم في موقع Greenfield أو شركتك الصغيرة؟ حسنًا ، إذا نجح نشاطك التجاري ، فستتمنى في غضون 30 عامًا أنك قد استجبت لحكمتي!

... بعض [الاعتراضات] كثيرا ما أسمع:

  • من الصعب نشر كود التحكم SP في قاعدة البيانات. لا أعتقد أن هذا أصعب من القول أنه من الصعب نشر كود التحكم في Java في خادم التطبيق ، وهذا يعني أنه ليس صعبًا على الإطلاق ، إنه أمر شائع. وأكثر من ذلك في روبي لاند ، تتم كتابة كتب كاملة حول كيفية الحصول على التعليمات البرمجية الخاصة بك من بيئة التطوير إلى الإنتاج ، وهو أمر لا يبدو أن مجتمع لغوي آخر يعاني منه. ومع ذلك ، يبدو أن النسخة التي تتحكم في الإجراء المخزن صعبة للغاية.
  • من الصعب اختبار الإجراءات المخزنة. هذا إجراء غريب. كبداية ، يتم كتابة SPs بقوة ؛ سيخبرك المترجم إذا كان هناك مسار كود داخل أو خارج غير منطقي ، وفي Oracle على الأقل ، سيحسب كل التبعيات لك. هذه مجموعة واحدة من اختبارات الوحدة الشائعة التي قد تحتاجها في Ruby التي تم التخلص منها. لاختبار رمز OO يتطلب السخرية لإرغام الكائن في الحالة الداخلية المطلوبة لتمثيل سيناريو الاختبار - كيف يختلف إعداد بيانات الاختبار؟ هناك منتج TAP لـ PL/SQL وأدوات أخرى إلى جانب ذلك. هناك مصححون ومحللون أيضًا.
  • لغة الإجراء المخزنة ليست لغة كاملة الميزات. حسنًا ، نحن لا نحاول كتابة تطبيق كامل في الإجراءات المخزنة فقط! تحتوي معظم لغات SP المخصصة على جميع التركيبات الحديثة التي تتوقعها ، وفي Oracle على الأقل ، يمكنك استخدام Java الإجراءات المخزنة مع جميع ميزات اللغة OO المطورين ، أو الإجراءات الخارجية بأي لغة. ما يهم هو المكان الذي يتم فيه تنفيذ المنطق - في مكان واحد ، بالقرب من البيانات - اللغة الفعلية هي مجرد تفاصيل. تجميع PL/SQL لتعليمات برمجية أصلية ويتم تشغيلها مع قاعدة البيانات لا توجد بنية أعلى أداء من ذلك.
  • لا أريد أن أتعلم لغة أخرى. بإطلالة لمدة ثانية ، هذه علامة حمراء كبيرة في أي مطور (خاصة واحدة تقترح تعديل تطبيقات الإنتاج التي قد تكون في لغة أخرى اللغات على أي حال!) هناك الكثير لتعلمه للعمل في أي بيئة حديثة: قد يكون لمتجر Java نموذجي Eclipse ، و WebLogic ، و Maven ، و Hudson ، و Anthill ، و Subversion ، ومجموعة كبيرة من الآخرين ، والتي تحتاجها تعلم قبل كتابة سطر واحد من كود التطبيق. تعتبر معرفة العمل بلغة SP عالية المستوى أمرًا مباشرًا بالمقارنة ، ومن المرجح أن يكون هناك أخصائي أو DBA لمساعدتك أيضًا. ناهيك عن أن Hibernate المفضلة للمطور تأتي مع لغة الاستعلام الخاصة بها ...

...

17
Gaius

هل يقوم SQL بأشياء مثل تعيين تصفية المنطق والنتائج الموجهة للتطبيق؟ SQL لغة معالجة رائعة.

بالإضافة إلى ذلك ، كما أشار GBN أعلاه ، فإن شفرة SQL ستفوق رمز التطبيق بشكل عام تقريبًا.

في حين أنه من الصحيح أن EF أو NHibernate أو LinqToSql أو أيا كان سيسمح لك بإنشاء التعليمات البرمجية بشكل أسرع ، فإن كل مبرمج يستحق أدائه يعرف أن تحسين SQL فقط هو الأمثل لاسترداد البيانات. يفهم نظام إدارة قواعد البيانات (RDBMS) لغة SQL فقط ، لذا يجب عليك تحويل كل شيء إلى لغة SQL قبل أن يتم قول ذلك وفعله. (بافتراض أنه يمكننا الاتفاق على أن TSQL و PLSQL لا يزالان SQL)

12
jcolebrand

أحد السلبيات التي لا يناقشها الناس بالضرورة - لقد استنفد المحترفون هنا - هو التكلفة.

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

11
Adam Musch

هنا حيث لا بد أن يحدث اجتماع العقول ، أي عقول المطورين (DVs) و DBAs. يمكن أن يكون للعمل مع منطق الأعمال (BL) وتخزينها في قاعدة بيانات تأثير يمكن أن يمجد أو يرعب تنفيذه.

بالنسبة لبعض منتجات RDBMS ، توجد مكتبات/أدوات/واجهات برمجة تطبيقات متفوقة لمنطق الأعمال والبنى التحتية للكائنات التي يمكن للمرء أن يتعلمها ويعمل بها بسرعة في تطبيقاتهم. بالنسبة لـ RDBMS الأخرى ، لا توجد مكتبات/أدوات/واجهات برمجة تطبيقات.

في الماضي ، جعلت تطبيقات خادم العميل الجسر إلى BL عبر الإجراءات المخزنة (SP). بالنسبة لمنتجات مثل Oracle و SQL Server ، تم ذلك مبكرًا. مع ظهور قواعد البيانات مفتوحة المصدر مثل PostgreSQL و MySQL ، كان أولئك الذين يستخدمونها معرضين لخطر فتح آفاق جديدة بالإجراءات المخزنة في BL. نضجت PostgreSQL بسرعة كبيرة في هذا الأمر ، نظرًا لأنه لم يتم تنفيذ الإجراءات المخزنة فحسب ، بل أيضًا القدرة على صياغة لغات العملاء. توقف MySQL بشكل أساسي عن التطور في عالم الإجراءات المخزنة وجاء في شكل لغة مجردة من اللغة مع العديد من القيود. وبالتالي ، عندما يتعلق الأمر بـ BL ، فأنت تحت رحمة MySQL ولغة الإجراء المخزن الخاصة بها.

لا يزال هناك سؤال واحد فقط: بغض النظر عن نظام إدارة قواعد البيانات العلمية ، هل يجب أن يكون BL موجودًا كليًا أو جزئيًا في قاعدة البيانات؟

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

قد يتمكن المطورون من صياغة طريقة عالية السرعة لتنفيذ BL بالاقتران مع تكوينات اللغة (أعلام المترجم لـ C++ ، إعدادات مختلفة لـ PHP/Python ، إلخ) عبر كائنات الأعمال الموجودة في الذاكرة بدلاً من قاعدة البيانات. حاول البعض ربط هذه الأيديولوجية من أجل تشغيل رمز أسرع في قاعدة البيانات عن طريق كتابة المكتبات حيث تم دمج تصحيح الأخطاء في الإجراءات المخزنة والمشغلات بشكل جيد في قاعدة البيانات ولا يبدو أنها قابلة للاستخدام.

وبالتالي ، فإن المطور يواجه تحديًا في تطوير شفرة المصدر و BL وتصحيحها والحفاظ عليها في لغتين.

الآن فكر في DBA. يرغب DBA في إبقاء قاعدة البيانات ضعيفة ويعني قدر الإمكان في مجال الإجراءات المخزنة. قد يرى DBA BL كشيء خارجي لقاعدة البيانات. ومع ذلك ، عندما تستدعي SQL البيانات المطلوبة لـ BL ، يجب أن يكون SQL نحيفًا ومتوسطًا.

الآن ، لقاء العقول !!!

رموز مطوري البرامج SP ويستخدم أساليب تفاعلية. تنظر DBA إلى SP. يحدد DBA أن عبارة SQL واحدة يمكن أن تحل محل الأساليب التفاعلية التي كتبها المطور. يرى المطور أن عبارة SQL التي اقترحها DBA تتطلب استدعاء التعليمات البرمجية الأخرى المتعلقة بـ BL أو SQL التي لا تتبع خطط التنفيذ العادية لعبارة SQL.

في ضوء ذلك ، يصبح التكوين وضبط الأداء و SP الترميز دالة لعمق وكثافة البيانات لـ BL لاسترداد البيانات. كلما زاد عمق البيانات وكثافة البيانات ، يجب أن يكون المطورون و DBA على نفس الصفحة لكمية البيانات وقوة المعالجة الممنوحة لقاعدة البيانات.

استنتاج

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

7
RolandoMySQLDBA

إنه سؤال جيد أن تطرحه على موقع ويب مليء بقواعد DBA. نأمل أن تكون معظم الإجابات "احترافية" تجاه الاحتفاظ بقاعدة البيانات في حالة ACID ، وبالتالي الحفاظ على منطق الأعمال في قاعدة البيانات. : -)

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

4
Ruud van de Beeten

كما قال آدم موسك أعلاه ، هناك المزيد للنظر في الأداء. استخدام المعالج. استخدام الذاكرة.

منع الأشياء الخاطئة بشكل واضح من الوصول إلى قاعدة البيانات.

  • تخلص من عناوين البريد الإلكتروني التي لا تتوافق بشكل أساسي.
  • تحقق أطوال

عندما تزداد عمقًا ، يجب اتخاذ القرارات. خادم DB هو مكان مكلف للغاية للقيام بأشياء يمكن للعميل القيام بها بسهولة. مثال: تنسيق البيانات ، تنسيق التواريخ ، تجميع السلاسل ، إلخ جانب العميل.

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

استخدم نقاط القوة لكل طرف لصالحك.

2
Matt M