ما هي إيجابيات وسلبيات الاحتفاظ بـ SQL في Stored Procs مقابل Code [مغلق]

Question

ما هي مزايا/عيوب الاحتفاظ بـ SQL في كود مصدر C# الخاص بك أو في Stored Procs؟لقد ناقشت هذا الأمر مع صديق في مشروع مفتوح المصدر نعمل عليه (منتدى C# ASP.NET).في الوقت الحالي، يتم معظم الوصول إلى قاعدة البيانات عن طريق إنشاء SQL مضمّن في C# والاتصال بقاعدة بيانات SQL Server.لذلك أحاول تحديد أيهما سيكون الأفضل لهذا المشروع بالذات.

حتى الآن لدي:

المزايا في الكود:

• أسهل في الصيانة - لا تحتاج إلى تشغيل برنامج نصي SQL لتحديث الاستعلامات
• أسهل في النقل إلى قاعدة بيانات أخرى - لا توجد إجراءات للمنفذ

مزايا العمليات المخزنة:

• أداء
• حماية

Answer 1

أنا لست من محبي الإجراءات المخزنة

تعتبر الإجراءات المخزنة أكثر قابلية للصيانة للأسباب التالية:* ليس عليك إعادة ترجمة تطبيق C# الخاص بك عندما تريد تغيير بعض SQL

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

• ينتهي بك الأمر إلى إعادة استخدام كود SQL.

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

تكرار التعليمات البرمجية هو أسوأ شيء يمكنك القيام به عندما تحاول إنشاء تطبيق قابل للصيانة!

متفق عليه، وهذا هو السبب في أن procs المخزنة أمر سيء.من الأسهل بكثير إعادة بناء التعليمات البرمجية وتفكيكها (تقسيمها إلى أجزاء أصغر) إلى وظائف مقارنة بـ SQL إلى...كتل SQL؟

لديك 4 خوادم ويب ومجموعة من تطبيقات Windows التي تستخدم نفس كود SQL الآن أدركت أن هناك مشكلة صغيرة في كود SQl فهل تفضل ذلك......غيّر الإجراء في مكان واحد أو ادفع الرمز إلى جميع خوادم الويب، وأعد تثبيت جميع تطبيقات سطح المكتب (قد يساعد النقر مرة واحدة) في جميع مربعات Windows

لماذا تتصل تطبيقات Windows الخاصة بك مباشرة بقاعدة بيانات مركزية؟يبدو هذا بمثابة ثغرة أمنية ضخمة هناك، كما أنه يمثل عنق الزجاجة لأنه يستبعد التخزين المؤقت من جانب الخادم.ألا ينبغي أن يكونوا متصلين عبر خدمة ويب أو ما يشبه خوادم الويب الخاصة بك؟

إذن، هل تريد دفع sproc واحد جديد أو 4 خوادم ويب جديدة؟

في هذه الحالة عليه يكون من الأسهل دفع sproc جديد واحد، ولكن في تجربتي، 95٪ من "التغييرات المدفوعة" تؤثر على الكود وليس قاعدة البيانات.إذا كنت تدفع 20 شيئًا إلى خوادم الويب في ذلك الشهر، وشيئًا واحدًا إلى قاعدة البيانات، فلن تخسر الكثير إذا قمت بدلاً من ذلك بدفع 21 شيئًا إلى خوادم الويب، وصفرًا إلى قاعدة البيانات.

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

هل يمكنك شرح كيف؟أنا لا أفهم هذا.خاصة وأن Sprocs ربما لا تكون في التحكم بالمصادر، وبالتالي لا يمكن الوصول إليها عبر متصفحات SCM المستندة إلى الويب وما إلى ذلك.

المزيد من السلبيات:

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

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

Answer 2

تتم مناقشة هذا في بعض المواضيع الأخرى هنا حاليًا.أنا مؤيد ثابت للإجراءات المخزنة، على الرغم من تقديم بعض الحجج الجيدة لـ Linq إلى Sql.

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

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

[عدل] هنا شيء آخر المناقشة الحالية

Answer 3

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

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

(Pseudocode)

Function createOrder(Order yourOrder) 
Begin
  Call SP_createOrder(yourOrder)
End

لذا في النهاية، لديك الطبقة الوسطى الخاصة بك تعمل على مجموعة الخوادم الأربعة الرائعة جدًا، كل منها مجهز بـ 16 وحدة معالجة مركزية ولن تفعل شيئًا على الإطلاق!يا للتبذير!

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

Answer 4

المزايا في الكود:

• أسهل في الصيانة - لا تحتاج إلى تشغيل برنامج نصي SQL لتحديث الاستعلامات
• أسهل في النقل إلى قاعدة بيانات أخرى - لا توجد إجراءات للمنفذ

في الواقع، أعتقد أن لديك ذلك إلى الوراء.IMHO، SQL في التعليمات البرمجية أمر مؤلم للحفاظ عليه للأسباب التالية:

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

فكر في Stored Procs كطرق تستدعيها من كائن قاعدة البيانات - فهي أسهل بكثير في إعادة استخدامها، ويوجد مكان واحد فقط للتعديل وفي حالة قيامك بتغيير موفري قاعدة البيانات، فإن التغييرات تحدث في Stored Procs الخاص بك وليس في التعليمات البرمجية الخاصة بك .

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

Answer 5

يخدع

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

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

الايجابيات

1. الأداء الذي قد يستحقه (يتجنب تحليل الاستعلام بواسطة برنامج تشغيل قاعدة البيانات/استجمام الخطة وما إلى ذلك)
2. لا يتم تضمين معالجة البيانات في كود C/C++/C# مما يعني أن لدي كودًا منخفض المستوى أقل للبحث فيه.SQL أقل تفصيلاً وأسهل في البحث عند إدراجها بشكل منفصل.
3. نظرًا للفصل، أصبح بمقدور الأشخاص العثور على كود SQL وإعادة استخدامه بسهولة أكبر.
4. من الأسهل تغيير الأشياء عندما يتغير المخطط - كل ما عليك فعله هو إعطاء نفس الإخراج للكود وسيعمل بشكل جيد
5. أسهل للنقل إلى قاعدة بيانات مختلفة.
6. يمكنني إدراج الأذونات الفردية في إجراءاتي المخزنة والتحكم في الوصول على هذا المستوى أيضًا.
7. يمكنني إنشاء ملف تعريف لاستعلام البيانات/رمز الثبات الخاص بي بشكل منفصل عن رمز تحويل البيانات الخاص بي.
8. يمكنني تنفيذ شروط قابلة للتغيير في الإجراء المخزن الخاص بي وسيكون من السهل تخصيصها في موقع العميل.
9. يصبح من الأسهل استخدام بعض الأدوات الآلية لتحويل المخطط والبيانات الخاصة بي معًا بدلاً من استخدامها عندما تكون مضمنة داخل الكود الخاص بي حيث يتعين علي مطاردتهم.
10. يكون ضمان أفضل الممارسات للوصول إلى البيانات أسهل عندما يكون لديك كل رموز الوصول إلى البيانات الخاصة بك داخل ملف واحد - يمكنني التحقق من الاستعلامات التي تصل إلى الجدول غير المؤدي أو الذي يستخدم مستوى أعلى من التسلسل أو تحديد * في الكود وما إلى ذلك .
11. يصبح من الأسهل العثور على تغييرات المخطط/تغييرات منطق معالجة البيانات عندما يتم إدراجها كلها في ملف واحد.
12. يصبح من الأسهل إجراء عمليات البحث واستبدال التعديلات على SQL عندما تكون في نفس المكان، على سبيل المثال.تغيير/إضافة بيانات عزل المعاملات لجميع العمليات المخزنة.
13. وجدت أنا ومسؤول DBA أن الحصول على ملف SQL منفصل هو أمر أسهل/ملائم عندما يتعين على DBA مراجعة عناصر SQL الخاصة بي.
14. وأخيرًا، لا داعي للقلق بشأن هجمات حقن SQL لأن بعض الأعضاء الكسالى في فريقك لم يستخدموا الاستعلامات ذات المعلمات عند استخدام SQLs المضمنة.

Answer 6

غالبًا ما تكون ميزة الأداء للإجراءات المخزنة مهملة.

المزيد من المزايا للإجراءات المخزنة:

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

Answer 7

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

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

Answer 8

الإجراءات المخزنة.

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

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

Answer 9

مزايا الإجراءات المخزنة:

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

أقل اقترانًا، وبالتالي يتم اختباره بسهولة أكبر.

ضبطها بسهولة أكبر.

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

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

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

سلبيات:

من الصعب إدارتها للمطورين:التحكم في إصدار البرامج النصية:هل كل شخص لديه قاعدة بيانات خاصة به، هل نظام التحكم في الإصدار متكامل مع قاعدة البيانات وIDE؟

Answer 10

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

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

والشيء الرائع الآخر في هذه التقنية هو أنه إذا كنت تبحث في ملف تعريف SQL، فيمكنك رؤية الاستعلام الذي قمت بإنشائه وتصحيحه بشكل أسهل بكثير من رؤية استدعاء proc مخزن يحتوي على 20 معلمة.

Answer 11

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

من أشد المعجبين بـ Transact SQL، لقد أثبت ضبط الاستعلامات الكبيرة أنه مفيد جدًا بالنسبة لي.لم أكتب أي SQL مضمنة منذ حوالي 6 سنوات!

Answer 12

قمت بإدراج نقطتين مؤيدتين لـ sprocs:

الأداء - ليس حقا.في Sql 2000 أو أكبر، تكون تحسينات خطة الاستعلام جيدة جدًا ومخزنة مؤقتًا.أنا متأكد من أن Oracle وغيرها تفعل أشياء مماثلة.لا أعتقد أن هناك مبررًا للأداء بعد الآن.

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

هذه أفضل ممارسة للأداء على أي حال.

Linq هي بالتأكيد الطريقة التي سأتبعها في مشروع جديد الآن.انظر الى هذا وظيفة مماثلة.

Answer 13

@ كيث

حماية؟لماذا تكون sprocs أكثر أمانًا؟

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

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

Answer 14

أعتقد أنه من هذا الطريق

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

أفضّل العمليات المخزنة

من الأسهل أيضًا إجراء اختبار الأداء ضد PROC ، وضعه في محلل الاستعلام الإحصائيات IO/Time على SET showplan_text On و Voila

لا حاجة لتشغيل ملف التعريف لمعرفة ما يتم استدعاؤه بالضبط

فقط 2 سنتي

Answer 15

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

كما أن الإجراءات المخزنة ليست أكثر أمانًا بطبيعتها.يمكنك كتابة استعلام سيئ باستخدام sproc بنفس السهولة المضمّنة.يمكن أن تكون الاستعلامات المضمنة ذات المعلمات آمنة تمامًا مثل sproc.

Answer 16

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

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

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

Answer 17

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

وأيضًا، كما أشار MatthieuF، يمكن تحسين الأداء كثيرًا نظرًا لتقليل عدد الرحلات ذهابًا وإيابًا بين التطبيق (سواء كان على سطح مكتب أو خادم ويب) وخادم قاعدة البيانات.

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

سأضع أيضًا فحوصات في عمود الزائد لوضع برمجة SQL في أيدي المتخصصين فيها، ولمقدمي الخدمات مما يسهل عزل التعليمات البرمجية واختبارها/تحسينها.

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

Answer 18

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

Answer 19

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

Answer 20

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

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

Answer 21

نحن نستخدم الإجراءات المخزنة مع قاعدة بيانات Oracle حيث أعمل الآن.نحن نستخدم أيضًا التخريب.يتم إنشاء كافة الإجراءات المخزنة كملفات .pkb & .pks ويتم حفظها في Subversion.لقد قمت بعمل SQL في السطر من قبل وهو أمر مؤلم!أفضّل كثيرًا الطريقة التي نقوم بها هنا.يعد إنشاء واختبار الإجراءات المخزنة الجديدة أسهل بكثير من القيام بذلك في التعليمات البرمجية الخاصة بك.

هناك

Answer 22

سجلات أصغر

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

Answer 23

أنا لست من أشد المعجبين بالإجراءات المخزنة، لكني أستخدمها بشرط واحد:

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

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

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

Answer 24

لا يؤدي proc SQL المخزن إلى زيادة أداء الاستعلام

Answer 25

حسنًا، من الواضح أن استخدام الإجراءات المخزنة له العديد من المزايا مقارنةً ببناء SQL في التعليمات البرمجية.

1. يصبح تنفيذ التعليمات البرمجية وSQL مستقلين عن بعضهما البعض.
2. الكود أسهل في القراءة.
3. اكتب مرة واحدة استخدم عدة مرات.
4. تعديل مرة واحدة
5. لا حاجة لإعطاء تفاصيل داخلية للمبرمج حول قاعدة البيانات.الخ الخ

Answer 26

الإجراءات المخزنة هي أكثر قابلة للصيانة بسبب:

• ليس عليك إعادة ترجمة تطبيق C# الخاص بك عندما تريد تغيير بعض SQL
• ينتهي بك الأمر إلى إعادة استخدام كود SQL.

تكرار الكود هو أسوأ الشيء الذي يمكنك القيام به عندما تحاول إنشاء تطبيق قابل للصيانة!

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

في رأيي، تعتبر مكاسب الأداء والأمان ميزة إضافية. لا يزال بإمكانك كتابة إجراءات SQL المخزنة غير الآمنة/غير الفعالة.

أسهل في النقل إلى قاعدة بيانات أخرى - لا توجد إجراءات للمنفذ

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

Answer 27

@Terrapin - sprocs معرضة تمامًا لهجمات الحقن.كما قلت:

قم دائمًا بتحديد جميع الاستعلامات - لا تقم أبدًا بتضمين أي شيء من إدخال المستخدم وستكون بخير.

هذا ينطبق على sprocs و Sql الديناميكي.

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

---

@Guy - نعم أنت على حق، تتيح لك sprocs التحكم في مستخدمي التطبيق حتى يتمكنوا من تنفيذ sproc فقط، وليس الإجراء الأساسي.

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

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

لا يزال من الممكن إجراء عمليات حقن Sql مقابل تلك sprocs إذا كانت تحتوي على تعليمات برمجية مضمنة ديناميكيًا، لذلك لا تزال القاعدة الذهبية سارية، حيث يجب دائمًا تحديد جميع مدخلات المستخدم.

Answer 28

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

ومع ذلك، فإن اللغات المستخدمة لكتابة الإجراءات المخزنة (PL/SQL مثال سيء السمعة) هي لغات وحشية جدًا.إنهم عادةً لا يقدمون أيًا من التفاصيل الدقيقة التي تراها في اللغات الحتمية الشائعة اليوم أو OOP أو اللغات الوظيفية.فكر في كوبول.

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

Answer 29

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

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

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

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

Answer 30

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

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

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