هل الإجراءات المخزنة أكثر كفاءة بشكل عام من البيانات المضمنة في أنظمة RDBMS الحديثة؟[ينسخ]

Question

هذا السؤال لديه بالفعل إجابة هنا:

• ايهما افضل:الاستعلامات المخصصة أو الإجراءات المخزنة؟[مغلق] 22 إجابة

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

أنا متأكد تمامًا من أن هذا يرتكز على سياق تاريخي حيث كان هذا هو الحال في السابق.الآن، أنا لا أدافع عن عدم الحاجة إلى العمليات المخزنة، ولكن أريد أن أعرف في أي الحالات تكون الإجراءات المخزنة ضرورية في قواعد البيانات الحديثة مثل MySQL، أو SQL Server، أو Oracle، أو <أدخل_قاعدة بياناتك_هنا>.هل من المبالغة أن يكون لديك حق الوصول الكامل من خلال الإجراءات المخزنة؟

Answer 1

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

لقد عملت بشكل متقطع في Sybase ASE وMySQL وSQL Server DBA منذ ما يقرب من عقد من الزمن (جنبًا إلى جنب مع تطوير التطبيقات في C وPHP وPL/SQL وC#.NET وRuby).لذا، ليس لدي فأس محدد أطحنه في هذه الحرب المقدسة (أحيانًا).

كانت فائدة الأداء التاريخي للعمليات المخزنة عمومًا مما يلي (بدون ترتيب معين):

• SQL التي تم تحليلها مسبقًا
• خطة تنفيذ الاستعلام التي تم إنشاؤها مسبقًا
• تقليل زمن وصول الشبكة
• فوائد ذاكرة التخزين المؤقت المحتملة

SQL التي تم تحليلها مسبقًا - فوائد مماثلة للتجميع مقابل.التعليمات البرمجية المفسرة، إلا على المستوى الجزئي للغاية.

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

خطة تنفيذ الاستعلام التي تم إنشاؤها مسبقًا.إذا كان لديك العديد من عمليات JOIN، فمن الممكن أن تصبح التباديل غير قابلة للإدارة تمامًا (أدوات التحسين الحديثة لها حدود وقطع لأسباب تتعلق بالأداء).ليس من المعروف أن SQL معقدة للغاية لديها فترات استجابة مميزة وقابلة للقياس (لقد رأيت استعلامًا معقدًا يستغرق أكثر من 10 ثوانٍ فقط لإنشاء خطة، قبل أن نقوم بتعديل نظام إدارة قواعد البيانات) بسبب فترات استجابة المُحسِّن الذي يحاول اكتشاف "أقرب أفضل" "خطة التنفيذ.ستقوم الإجراءات المخزنة عمومًا بتخزين هذا في الذاكرة حتى تتمكن من تجنب هذا الحمل.

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

أيضًا، يسمح لك المزيد والمزيد من أنظمة إدارة قواعد البيانات (DBMS) بتوفير خطط مسار مُحسّن (خطط استعلام مجردة) لتقليل وقت التحسين بشكل كبير (لكل من الإجراء المخصص والمخزن SQL !!).

تحذير خطط الاستعلام المخزنة مؤقتًا ليست حلاً سحريًا للأداء.في بعض الأحيان تكون خطة الاستعلام التي تم إنشاؤها دون المستوى الأمثل.على سبيل المثال، إذا قمت بإرسال SELECT * FROM table WHERE id BETWEEN 1 AND 99999999, ، قد تحدد DBMS فحصًا كاملًا للطبقة بدلاً من فحص الفهرس لأنك تمسك بكل صف في الجدول (لذا حدد الإحصائيات).إذا كان هذا هو الإصدار المخطط مؤقتًا ، فيمكنك الحصول على أداء ضعيف عند إرساله لاحقًا SELECT * FROM table WHERE id BETWEEN 1 AND 2.المنطق وراء هذا هو خارج نطاق هذا المنشور ، ولكن لمزيد من القراءة انظر: http://www.microsoft.com/technet/prodtechnol/sql/2005/frcqupln.mspxو http://msdn.microsoft.com/en-us/library/ms181055.aspxو http://www.simple-talk.com/sql/performance/execution-plan-basics/

"باختصار ، قرروا أن توفير أي شيء آخر غير القيم المشتركة عند تنفيذ ترجمة أو إعادة ترجمة أدى إلى تجميع المحسن وتخزينه في خطة الاستعلام لتلك القيمة الخاصة.ومع ذلك ، عندما تم إعادة استخدام خطة الاستعلام هذه لعمليات الإعدام اللاحقة لنفس الاستعلام للقيم المشتركة ("M" أو "R" أو "T") ، فقد أدى إلى أداء دون المستوى الأمثل.كانت مشكلة الأداء دون المستوى الأمثل موجودة حتى يتم إعادة ترجمة الاستعلام.عند هذه النقطة ، استنادًا إلى قيمة المعلمة @P1 المقدمة ، قد يواجه الاستعلام أو لا يواجه مشكلة في الأداء. "

تقليل زمن وصول الشبكةأ) إذا كنت تقوم بتشغيل نفس SQL مرارًا وتكرارًا - ويضيف SQL ما يصل إلى العديد من كيلوبايت من التعليمات البرمجية - فإن استبدال ذلك بـ "exec foobar" البسيط يمكن أن يضيف شيئًا حقًا.ب) يمكن استخدام العمليات المخزنة لنقل التعليمات البرمجية الإجرائية إلى نظام إدارة قواعد البيانات.يؤدي هذا إلى توفير خلط كميات كبيرة من البيانات إلى العميل فقط ليتمكن من إرسال القليل من المعلومات مرة أخرى (أو لا شيء على الإطلاق!).مشابه للقيام بـ JOIN في نظام إدارة قواعد البيانات (DBMS) مقابل نظام إدارة قواعد البيانات (DBMS).في الكود الخاص بك (WTF المفضل لدى الجميع!)

لا تزال ميزة؟أ) شبكة إيثرنت الحديثة بسرعة 1 جيجا بايت (و 10 جيجا بايت وما فوق!) تجعل هذا الأمر لا يكاد يذكر.ب) يعتمد على مدى تشبع شبكتك - لماذا يتم نقل عدة ميغابايت من البيانات ذهابًا وإيابًا دون سبب وجيه؟

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

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

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

معلمات / SQL المعدة
نوع من التقاطع بين الإجراءات المخزنة وSQL المخصصة، فهي عبارة عن عبارات SQL مضمنة في لغة مضيفة تستخدم "معلمات" لقيم الاستعلام، على سبيل المثال:

SELECT .. FROM yourtable WHERE foo = ? AND bar = ?

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

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

لا يزال العيب؟ليس بالضرورة.تتمتع معظم أنظمة إدارة قواعد البيانات بالقدرة على "تجريد" SQL المخصصة إلى إصدارات ذات معلمات - وبالتالي إلغاء الفرق بين الاثنين بشكل أو بآخر.يقوم البعض بذلك بشكل ضمني أو يجب تمكينه من خلال إعداد الأمر (خادم SQL: http://msdn.microsoft.com/en-us/library/ms175037.aspx ، وحي: http://www.praetorate.com/Oracle_tips_cursor_sharing.htm).

الدروس المستفادة؟يستمر قانون مور في المضي قدمًا، ويصبح مُحسِّنو نظام إدارة قواعد البيانات (DBMS) أكثر تطورًا مع كل إصدار.بالتأكيد، يمكنك وضع كل عبارة SQL صغيرة وسخيفة داخل عملية مخزنة، ولكن اعلم فقط أن المبرمجين الذين يعملون على أدوات تحسين الأداء أذكياء للغاية ويبحثون باستمرار عن طرق لتحسين الأداء.في النهاية (إذا لم يكن موجودًا بالفعل) سيصبح أداء SQL المخصص غير قابل للتمييز (في المتوسط!) عن أداء الإجراء المخزن، لذا فإن أي نوع من جَسِيم استخدام الإجراء المخزن ** فقط "لأسباب تتعلق بالأداء"** يبدو بالتأكيد وكأنه تحسين سابق لأوانه بالنسبة لي.

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

Answer 2

أسباب استخدام الإجراءات المخزنة:

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

Answer 3

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

Answer 4

إنه نقاش يحتدم باستمرار (على سبيل المثال، هنا).

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

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

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

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

يحرر:ورغم أن مقالة فرانس بوما مطولة بالفعل، إلا أنها تخطئ النقطة المتعلقة بالأمن بفارق كبير.حقيقة أن عمرها 5 سنوات لا تساعد في أهميتها أيضًا.

Answer 5

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

لاحظ أن الاستعلام ذي المعلمات ليس هو نفسه استعلام SQL المخصص.

السبب الرئيسي وراء استمرار المنظمة البحرية الدولية في تفضيل الإجراءات المخزنة اليوم له علاقة بالأمان.إذا كنت تستخدم الإجراءات المخزنة حصريا, ، يمكنك تعطيل أذونات INSERT وSELECT وUPDATE وDELETE وALTER وDROP وCREATE وغيرها لمستخدم التطبيق الخاص بك، مع ترك الأمر EXECUTE فقط.

وهذا يوفر القليل من الحماية الإضافية ضد الترتيب الثاني حقن SQL.الاستعلامات ذات المعلمات تحمي فقط من الترتيب الأول حقنة.

Answer 6

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

1. مطورو التطبيقات ليسوا دائمًا أفضل برامج ترميز SQL.الإجراءات المخزنة تخفي SQL من التطبيق.

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

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

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

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

Answer 7

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

Answer 8

في عام 2007 كنت في مشروع، حيث استخدمنا MS SQL Server عبر ORM.كان لدينا جدولان كبيران ومتزايدان استغرقا ما يصل إلى 7-8 ثوانٍ من وقت التحميل على SQL Server.بعد إنشاء إجراءين كبيرين ومخزنين لـ SQL، وتحسينهما من مخطط الاستعلام، انخفض كل وقت تحميل لقاعدة البيانات إلى أقل من 20 مللي ثانية، لذلك من الواضح أنه لا تزال هناك أسباب تتعلق بالكفاءة لاستخدام إجراءات SQL المخزنة.

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

قدم مورد ORM لدينا الادعاء المعتاد بأن إطلاق العديد من استعلامات SQL الصغيرة سيكون أكثر كفاءة من جلب مجموعات البيانات الكبيرة والمنضمة.أظهرت تجربتنا (لدهشتنا) شيئًا آخر.

قد يختلف هذا بالطبع بين الأجهزة والشبكات وأنظمة التشغيل وخوادم SQL وأطر التطبيقات وأطر ORM وتطبيقات اللغة، لذا قم بقياس أي فائدة تعتقد أنك قد تحصل عليها من القيام بشيء آخر.

لم نكتشف أن المشكلة كانت بين ORM وقاعدة البيانات التي تتحمل كل العبء إلا بعد إجراء المقارنة المعيارية.

Answer 9

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

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

لذا فإن مشاعر العميل تتفوق على جميع الحجج الأخرى في هذه الحالة.

Answer 10

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

Answer 11

قراءة فرانس بوما وظيفة ممتازة (إذا كان متحيزًا بعض الشيء) على ذلك.

Answer 12

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

Answer 13

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

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

Answer 14

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

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

Answer 15

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

لدى فرانس بوما مقالة جيدة حول هذا الموضوع: http://weblogs.asp.net/fbouma/archive/2003/11/18/38178.aspx

Answer 16

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

عادةً ما أقوم باستدعاء التعليمات البرمجية بشكل متكرر كعملية مخزنة أو ككائن SqlCommand (.NET) وتنفيذها عدة مرات حسب الحاجة.

Answer 17

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

Answer 18

IMHO...

يمكن أن يؤدي تقييد عمليات "C_UD" إلى الإجراءات المخزنة إلى الاحتفاظ بمنطق تكامل البيانات في مكان واحد.ويمكن القيام بذلك أيضًا عن طريق تقييد عمليات "C_UD" على طبقة أدوات متوسطة واحدة.

يمكن توفير عمليات القراءة للتطبيق حتى يتمكنوا من الانضمام فقط إلى الجداول / الأعمدة التي يحتاجون إليها.

Answer 19

يمكن أيضًا استخدام الإجراءات المخزنة بدلاً من الاستعلامات ذات المعلمات (أو الاستعلامات المخصصة) لبعض المزايا الأخرى أيضًا:

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

Answer 20

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

التخزين المؤقت - لا يعاملهم MS-SQL بشكل مختلف، ليس منذ أن كان MS-SQL 2000 7 ولكني لا أتذكر.

الأذونات - ليست مشكلة لأن كل ما أفعله تقريبًا هو الويب أو لدي طبقة تطبيق متوسطة تقوم بالوصول إلى قاعدة البيانات بالكامل.البرنامج الوحيد الذي أعمل معه والذي يتمتع بإمكانية الوصول المباشر إلى قاعدة البيانات هو منتجات الجهات الخارجية المصممة للمستخدمين للوصول المباشر وتعتمد على منح المستخدمين أذونات.ونعم نموذج أمان إذن MS-SQL سيء !!!(لم أقضي وقتًا في عام 2008 بعد) كجزء أخير من هذا، أود أن أرى استطلاعًا حول عدد الأشخاص الذين ما زالوا يقومون ببرمجة العميل/الخادم المباشرة مقابل برمجة خادم الويب والتطبيقات المتوسطة؛وإذا كانوا يقومون بمشاريع كبيرة فلماذا لا يوجد ORM.

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

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

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

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

هجمات حقن SQL - لا توفر SP حماية أفضل.الشيء الوحيد الذي حصلوا عليه هو أن معظمهم يقومون بالتدريس باستخدام المعلمات مقابل SQL الديناميكي، حيث تتجاهل معظم الأمثلة المعلمات.