إعادة استخدام إجراءات SQL المخزنة عبر التطبيقات
https://stackoverflow.com/questions/84453
-
01-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russianسؤال
أشعر بالفضول بشأن الأساليب التي يتبعها الأشخاص في استخدام الإجراءات المخزنة في قاعدة بيانات يمكن الوصول إليها بواسطة العديد من التطبيقات.على وجه التحديد، هل تميل إلى الاحتفاظ بمجموعات مختلفة من الإجراءات المخزنة لكل تطبيق، أم تحاول استخدام مجموعة مشتركة، أم تقوم بمزيج؟
من ناحية، تسمح إعادة استخدام SPs بإجراء تغييرات أقل عندما يكون هناك تغيير في النموذج أو شيء مشابه وصيانة أقل بشكل مثالي.ومن ناحية أخرى، إذا تباينت احتياجات التطبيقات، فقد تؤدي التغييرات التي يتم إجراؤها على إجراء مخزن لتطبيق واحد إلى تعطيل التطبيقات الأخرى.يجب أن أشير إلى أنه في بيئتنا، كل تطبيق لديه فريق تطوير خاص به، مع ضعف التواصل بينهم.يتمتع فريق البيانات باتصالات أفضل، ويتم تكليفه في الغالب بكتابة الإجراءات المخزنة.
شكرًا!
المحلول
كل هذا يتوقف على استراتيجية التجريد الخاصة بك.هل يتم التعامل مع الإجراءات المخزنة كنقطة تجريد منفصلة، أم يتم التعامل معها على أنها مجرد جزء آخر من التطبيق الذي يستدعيها؟
الإجابة على ذلك ستخبرك بكيفية إدارتها.إذا كانت مجردة منفصلة، فيمكن مشاركتها، كما لو كنت بحاجة إلى وظيفة جديدة، فسوف تضيف إجراءات جديدة.إذا كانوا جزءًا من التطبيق الذي يتصل بهم، فلا ينبغي مشاركتهم.
نصائح أخرى
يجب إنشاء الإجراءات المخزنة بناءً على البيانات التي تنوي إرجاعها، وليس التطبيق الذي يقدم الطلب.إذا كان لديك إجراء مخزن هو GetAllItems، فيجب أن يقوم بإرجاع كافة العناصر الموجودة في قاعدة البيانات.إذا كان أحد التطبيقات يرغب في الحصول على كافة العناصر حسب الفئة، فقم بإنشاء GetAllItemsByCategory.لا يوجد سبب لتغيير قواعد العمل الخاصة بالإجراء المخزن بناءً على التطبيق الذي يطلب البيانات.
لقد كانت تجربتي أن مشاركة SPs بواسطة تطبيقات متعددة هو سبب للألم.في الواقع، أود أن أزعم أن وجود قاعدة بيانات يتم الوصول إليها مباشرة من خلال أكثر من تطبيق واحد ليس أفضل بنية على المدى الطويل.
النمط الذي أوصي به وقمت بتنفيذه هو أن تطبيقًا واحدًا فقط يجب أن "يمتلك" كل قاعدة بيانات، ويوفر واجهات برمجة التطبيقات (الخدمات، وما إلى ذلك) للتطبيقات الأخرى للوصول إلى البيانات وتعديلها.
وهذا له العديد من المزايا:
- يمكن للتطبيق المالك تطبيق أي منطق عمل أو تسجيل وما إلى ذلك.للتأكد من بقائها مستقرة
- إذا تم تغيير المخطط، فستكون جميع الواجهات معروفة ويمكن اختبارها للتأكد من أن التطبيقات الخارجية ستظل تعمل
يجب أن تكشف الإجراءات المخزنة عن قواعد العمل التي لا تتغير اعتمادًا على التطبيق الذي يستخدمها.يتيح ذلك تخزين القواعد وتحديثها مرة واحدة بدلاً من استخدامها في كل مكان، وهو ما يعتبر كابوسًا.
أعتقد أنه من هذا الطريق:تتعلق إجراءاتك المخزنة بالبيانات الموجودة تحتها، ولا ينبغي أن تكون على علم بالتطبيقات الموجودة فوقها.من الممكن أن يحتاج أحد التطبيقات إلى قراءة البيانات أو تحديثها بطريقة لا يفعلها تطبيق آخر، ولذلك يستخدم أحد التطبيقات مقدمي الخدمة (SPs) ولا يستخدمها الآخر.
إذا كان التطبيق / قاعدة البيانات / وما إلى ذلك، والتغييرات التي تم إجراؤها على SP لتحسين أحد التطبيقات قد أدت إلى تعطيل تطبيق آخر، فسأعتبر هذا دليلاً على وجود مشكلة تصميم أعمق.
الجزء الأخير من سؤالك أعتقد أنه أجاب على نفسه.
ومع ضعف الاتصال بالفعل، فإن إجراءات المشاركة بين فرق التطوير من شأنها أن تزيد من نقاط الفشل المحتملة ويمكن أن تسبب صعوبات لأي من الفريقين.
إذا كنت في نفس الفريق أعمل على مشاريع متعددة، فسنوفر بعض الوقت ونشارك الإجراءات، ولكن عادةً ما وجدت أن القليل من الازدواجية (بعض الإجراءات هنا وهناك) تساعد في تجنب التغييرات/التكرار الكارثي المطلوب لاحقًا عندما يتم تشغيل التطبيقات تبدأ في التباعد.
يشير LordScarlet أيضًا إلى عنصر أساسي أيضًا، إذا كان عامًا بدون مشاركة منطق العمل، فلا ينبغي أن يكون مشكلة.
كلما قمنا بتخزين إجراءات مشتركة بين تطبيقات متعددة، كنا نقوم بإنشاء قاعدة بيانات لتلك الإجراءات فقط (وطرق العرض والجداول، وما إلى ذلك).سيكون لقاعدة البيانات هذه (التي أطلقنا عليها اسم "القاعدة") مطور (أو فريق) مسؤول عنها (الصيانة والاختبار).
إذا احتاج فريق مختلف إلى وظيفة جديدة، فيمكنهم كتابتها وسيقوم المطور الأساسي إما بتنفيذها في قاعدة البيانات الأساسية أو اقتراح طريقة أبسط.
نحن نحاول استخدام عملية مخزنة واحدة ومشتركة حيثما كان ذلك ممكنًا، ولكننا واجهنا الموقف الذي وصفته أيضًا.لقد تعاملنا معها عن طريق إضافة بادئة تطبيق إلى procs المخزنة (ApplicationName_StoredProcName).
غالبًا ما تستدعي هذه العمليات المخزنة العملية المخزنة المركزية أو "الرئيسية"، ولكن هذه الطريقة تترك مجالًا لإجراء تغييرات محددة على التطبيق في المستقبل.
لا أعتقد أن مشاركة Sprocs بين تطبيقات متعددة أمر منطقي.
أستطيع أن أرى ضرورة مشاركة قاعدة بيانات في التطبيقات ذات الصلة، ولكن من المفترض أن تكون هذه التطبيقات منفصلة إلى حد كبير لأنها تتعامل مع البيانات بشكل مختلف تمامًا عن بعضها البعض.
يمكن أن يعمل استخدام نفس البنية عبر التطبيقات، ولكن تخيل أنك تحاول استخدام نفس طبقة منطق الأعمال في تطبيقات متعددة."لكن انتظر!" أنت تقول ، "هذا سخيف ...إذا كنت أستخدم نفس BLL، فلماذا يكون لدي تطبيق منفصل؟انهم يفعلون نفس الشيء!"
QED.
من الأفضل استخدام بروك واحد وليس إصدارات متعددة.إذا كنت بحاجة إلى إصدارات لكل عميل، فتحقق من فكرة 1 ديسيبل لكل عميل بدلاً من 1 ديسيبل لجميع العملاء.يسمح هذا أيضًا ببعض التدريج المثير للاهتمام لقواعد البيانات على خوادم مختلفة (تخصيص الخوادم الأكبر/الأثقل استخدامًا للخوادم الأكبر بينما يمكن للخوادم الأصغر مشاركة الأجهزة)
إذا كنت تبحث عن القدرة على مشاركة كود SQL، فحاول إنشاء مكتبة من الوظائف المجردة.بهذه الطريقة يمكنك إعادة استخدام بعض التعليمات البرمجية التي تقوم بأشياء عامة وتبقي منطق العمل منفصلاً لكل تطبيق.ويمكن فعل الشيء نفسه مع طرق العرض - حيث يمكن الاحتفاظ بها بشكل عام ومفيدة للعديد من التطبيقات.
من المحتمل أن تكتشف أنه لا يوجد العديد من الاستخدامات للإجراءات المخزنة الشائعة أثناء تقدمك.
ومع ذلك، قمنا ذات مرة بتنفيذ مشروع كان يعمل مع قاعدة بيانات قديمة مصممة بشكل سيء للغاية.لقد قمنا بتنفيذ مجموعة من الإجراءات المخزنة التي جعلت عملية استرجاع المعلومات سهلة.عندما أراد أشخاص آخرون من فرق أخرى استخدام نفس المعلومات، قمنا بإعادة هيكلة إجراءاتنا المخزنة لجعلها أكثر عمومية، وأضفنا طبقة إضافية من التعليقات والوثائق وسمحنا لأشخاص آخرين باستخدام إجراءاتنا.هذا الحل يعمل بشكل جيد إلى حد ما.
تعتبر العديد من الإجراءات المخزنة مستقلة عن التطبيق، ولكن قد يكون هناك عدد قليل منها يعتمد على التطبيق.على سبيل المثال، يمكن أن تنتقل الإجراءات المخزنة CRUD (إنشاء، تحديد، تحديث، حذف) عبر التطبيقات.على وجه الخصوص، يمكنك استخدام منطق التدقيق (يتم إجراؤه أحيانًا في المشغلات ولكن هناك حدًا لمدى التعقيد الذي يمكن أن تحصل عليه في المشغلات).إذا كان لديك نوع من البنية القياسية في متجر البرامج الخاص بك، فقد تتطلب الطبقة الوسطى إجراءً مخزنًا لإنشاء/تحديد/تحديث/حذف من قاعدة البيانات بغض النظر عن التطبيق وفي هذه الحالة تتم مشاركة الإجراء.
وفي نفس الوقت قد تكون هناك بعض الطرق المفيدة لعرض البيانات، مثل GetProductsSoldBySalesPerson، وما إلى ذلك.والتي ستكون أيضًا مستقلة عن التطبيق.قد يكون لديك مجموعة من جداول البحث لبعض الحقول مثل القسم والعنوان وما إلى ذلك.لذلك قد يكون هناك إجراء لإرجاع عرض الجدول بجميع حقول النص.أي بدلاً من SalesPersonID وSaleDate وCustomerID وDepartmentID وCustomerAddressID، يقوم الإجراء بإرجاع طريقة عرض SalesPersonName وSaleDate وCustomerName وDepartmentName وCustomerAddress.ويمكن استخدام هذا أيضًا عبر التطبيقات.قد يحتاج نظام علاقات العملاء إلى اسم العميل/العنوان/السمات الأخرى كما هو الحال في نظام الفوترة.لذا فإن الشيء الذي قام بجميع عمليات الانضمام وحصل على جميع معلومات العميل في استعلام واحد من المحتمل أن يتم استخدامه عبر التطبيقات.من المسلم به أن إنشاء طرق لعرض البيانات هو مجال العرض، ولكن غالبًا ما يستخدم الأشخاص الإجراءات المخزنة للقيام بذلك.
لذلك، عند الحذف من الجدول الخاص بك، هل تحتاج إلى الحذف من 3 أو 4 جداول أخرى لضمان سلامة البيانات.هل المنطق معقد للغاية بالنسبة للمشغل؟ثم قد يكون الإجراء المخزن الذي تستخدمه جميع التطبيقات لإجراء عمليات الحذف مهمًا.وينطبق الشيء نفسه على الأشياء التي يجب القيام بها عند الخلق.إذا كانت هناك صلات مشتركة يتم إجراؤها دائمًا، فقد يكون من المنطقي أن يكون لديك إجراء مخزن واحد للقيام بجميع الصلات.وبعد ذلك، إذا قمت لاحقًا بتغيير الجداول من حولك، فيمكنك الاحتفاظ بالإجراء كما هو وتغيير المنطق هناك.
يعد مفهوم مشاركة مخطط البيانات عبر تطبيقات متعددة أمرًا صعبًا.دائمًا ما يتم اختراق مخططك لأسباب تتعلق بالأداء:عدم التطبيع، الذي يفهرس لإنشاء.إذا كان بإمكانك قص حجم الصف إلى النصف، فيمكنك مضاعفة عدد الصفوف في كل صفحة، ومن المحتمل أن تقلل الوقت الذي يستغرقه فحص الجدول إلى النصف.ومع ذلك، إذا قمت بتضمين الميزات "المشتركة" فقط في الجدول الرئيسي واحتفظت فقط بالبيانات التي تهم تطبيقات معينة في جداول مختلفة (ولكنها مرتبطة)، فيجب عليك الانضمام إلى كل مكان للعودة إلى فكرة "الجدول الفردي".
سيؤدي المزيد من الفهارس لدعم التطبيقات المختلفة إلى زيادة الوقت لإدراج البيانات وتحديثها وحذفها من كل جدول.
غالبًا ما يصبح خادم قاعدة البيانات عنق الزجاجة أيضًا، لأنه لا يمكن موازنة تحميل قواعد البيانات.يمكنك تقسيم بياناتك عبر خوادم متعددة، لكن الأمر يصبح معقدًا للغاية أيضًا.
وأخيرا، فإن درجة التنسيق المطلوبة عادة ما تكون ضخمة، ولا شك في وجود معارك بين الإدارات المختلفة حول متطلباتها التي تحظى بالأولوية، وسوف تتعثر التطورات الجديدة.
بشكل عام، يعمل نموذج "مستودع البيانات المعزول لكل تطبيق" بشكل أفضل.يعتمد كل ما نقوم به تقريبًا - أعمل في شركة برمجيات تعاقدية - على استيراد البيانات من أنظمة أخرى وتصديرها إلى أنظمة أخرى، باستخدام قواعد البيانات الخاصة بتطبيقاتنا.
قد يكون الأمر أسهل في مستودعات البيانات/أنظمة دعم القرار؛أعمل عمومًا على أنظمة OLTP حيث يكون أداء المعاملات أمرًا بالغ الأهمية.
