هل يجب علينا إسقاط الإجراءات المخزنة وتشغيل مكالمات قاعدة البيانات من برامج Java

Question

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

الرجاء المساعدة في حجتي للحفاظ على الإجراءات المخزنة حية في شركتي.

Answer 1

حسنًا ، سأخرج لصالح بروكس المخزنة.

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

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

كما أنها أسهل في لحن الأداء حيث يمكن استدعاؤها بسهولة دون إطلاق التطبيق.

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

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

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

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

Answer 2

لن تعجبك هذا ، وربما سأقدم في غياهب النسيان ، لكنني مع بقية comapny.

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

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

إذا كنت تريد المزيد من التفاصيل حول الحجج للابتعاد عن procedures المخزنة ، تحقق من مقالة CodingHorror هذه:

ترميز الرعب: من يحتاج إلى إجراءات مخزنة على أي حال؟

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

Answer 3

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

يرجى ملاحظة أنه يمكنك كتابة الإجراءات المخزنة في أي لغة IBM I بما في ذلك Java ، في حال كانت مسألة مهارات البرمجة. أيضًا ، يمكنك الوصول إلى الجهاز الكامل ، وليس فقط بعض الأدوات الداخلية لقاعدة البيانات. هنا يختلف AS/400 اختلافًا كبيرًا عن أي منتج قاعدة بيانات أخرى ، بحيث يختبر من قواعد البيانات الأخرى ببساطة - في لي الرأي - لا ينطبق.

أود أن أوصي بقوائم البريد المتوسطة المدى لأنها لديها أكبر تركيز من/400 مهارات البرمجة التي أعرفها.

Answer 4

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

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

هناك شيئان كبيران لصالح الإجراءات المخزنة. الأول هو أن الأشخاص الذين يعرفون PL/SQL من المرجح أن يكونوا على دراية بقواعد بيانات Oracle (T-SQL & SQL Server ، إلخ) ، وبالتالي يميلون إلى كتابة برامج أفضل لهذه قاعدة البيانات (المعرّفة كبرامج تستفيد من النظام الأساسي الميزات ومجودة وظائفها) من الأشخاص الذين لا يفعلون ذلك.

الشيء الثاني هو أن البيانات لا تزال قائمة. مطورو التطبيقات مولعون بالحديث عن "استقلال قاعدة البيانات" ولكن ما يهم حقًا استقلال التطبيق. تأتي الواجهة الأمامية وتذهب ولكن نموذج البيانات يدوم إلى الأبد. في السنوات العشر الماضية ، تمت كتابة تطبيقات Java كتطبيقات و Servlets و JSPs والبلاط والوجوه ، مع الوظائف الإضافية في JavaScript و Groovy و Ajax و JSON ، والتي تتصل بقاعدة البيانات من خلال JDBC المغطى باليد ، EJB (v1،2 ، 3) ، Toplink ، السبات وإيباتيس ... سامحني إذا فاتني عدد قليل. من السهل ترقية التطبيقات التي تعتبر واجهة المستخدم الخاصة بها على طبقة من الإجراءات المخزنة إلى أحدث وأكبر التطبيقات التي يجب إعادة كتابة منطق العمل في كل مرة. وسيؤدون أداء أفضل أيضًا.

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

Answer 5

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

لكن حسنًا ، هذا أنا فقط.

Answer 6

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

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

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

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

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