هل من الغباء كتابة برنامج معالجة دفعات كبيرة بالكامل في PL/SQL؟
https://stackoverflow.com/questions/78626
-
09-06-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russianسؤال
لقد بدأت العمل على برنامج ربما يكون من الطبيعي وصفه بأنه مجموعة من العمليات الحسابية على جداول قاعدة البيانات، وسيتم تنفيذه مرة واحدة في الشهر.جميع المدخلات موجودة في جداول قاعدة بيانات أوراكل، وستكون جميع المخرجات في جداول قاعدة بيانات أوراكل.يجب أن يظل البرنامج قابلاً للصيانة لسنوات عديدة قادمة.
يبدو من السهل تنفيذ ذلك كسلسلة من الإجراءات المخزنة، يؤدي كل منها تحولاً معقولاً، على سبيل المثال توزيع التكاليف بين الأقسام وفقًا لبعض قواعد العمل.يمكنني بعد ذلك كتابة اختبارات الوحدة للتحقق مما إذا كان ناتج كل تحويل كما توقعت.
هل هي فكرة سيئة القيام بكل هذا في PL/SQL؟هل تفضل إجراء عمليات حسابية دفعة كبيرة باستخدام لغة برمجة نموذجية موجهة للكائنات، مثل C#؟أليس من الأكثر تعبيرًا استخدام لغة برمجة تتمحور حول قاعدة البيانات مثل PL/SQL؟
المحلول
عادةً ما أقول ضع أقل قدر ممكن من PL/SQL - وعادةً ما تكون أقل قابلية للصيانة - في إحدى وظائفي الأخيرة، رأيت حقًا مدى الفوضى والصعوبة في العمل بها.
ومع ذلك، نظرًا لأنها معالجة مجمعة - وبما أن المدخلات والمخرجات كلاهما عبارة عن قاعدة بيانات - فمن المنطقي وضع المنطق في PL/SQL - لتقليل "الأجزاء المتحركة".ومع ذلك، إذا كان الأمر يتعلق بمنطق الأعمال - أو المكونات المستخدمة بواسطة أجزاء أخرى من نظامك - فأنا أقول لا تفعل ذلك..
نصائح أخرى
قمت بوصف المتطلبات التالية
أ) يجب أن تكون قادرة على تنفيذ معالجة الدُفعات ب) يجب أن تكون النتيجة قابلة للصيانة
جوابي:
- تم تصميم PL/SQL لتحقيق ما تصفه فقط.من المهم أيضًا ملاحظة أن هناك كفاءات في PL/SQL غير متوفرة في الأدوات الأخرى.تضع لغة الإجراء المخزنة المعالجة بجوار البيانات - وهو المكان الذي يجب أن تتم فيه معالجة الدُفعات.
- من السهل كتابة تعليمات برمجية سيئة الصيانة بأي لغة.
وبعد قول ما سبق، فإن تنفيذك سيعتمد على المهارات المتاحة والتصميم المناسب والالتزام بعمليات الجودة الجيدة.
لكي يكون التنفيذ فعالاً، يجب أن يعالج البيانات على دفعات (حدد على دفعات وأدخل/تحديث على دفعات).الخطر في نهج OO هو أنه من السهل أن يتم توجيهك نحو تصميم يعالج صفًا تلو الآخر من البيانات.يحتوي هذا النوع من الأساليب على تكاليف غير ضرورية، وسيكون أقل كفاءة بشكل ملحوظ من التصميم الذي يعالج البيانات على دفعات من الصفوف.
من الممكن استخدام كلا الطريقتين بنجاح.
ماثيو بتلر
شيء يجب أن يلاحظه المعلقون الآخرون - السؤال يتعلق بـ PL/SQL، وليس حول SQL.من الواضح أن بعض الإجابات كانت تتعلق بـ SQL، وليس PL/SQL.PL/SQL هي لغة قاعدة بيانات كاملة الوظائف، كما أنها ناضجة أيضًا.هناك بعض أوجه القصور، ولكن بالنسبة لنوع الشيء الذي يريد الملصق القيام به، فهو جيد جدًا.
لا، ليست بالضرورة فكرة سيئة.إذا كان الحل يبدو واضحًا بالنسبة لك ويسمح لك باختبار كل عملية والتحقق منها، فيبدو أنها قد تكون فكرة جيدة.يمكن أن تكون منصات OO (على الرغم من أنها لا يجب أن تكون كذلك) سيئة بالنسبة لمجموعات البيانات الكبيرة، حيث أن إنشاء الكائنات والحمل الزائد يمكن أن يؤدي إلى توقف الأداء.
صممت Oracle PL/SQL مع وضع مشكلات مثل مشكلتك في الاعتبار، إذا كانت هناك معرفة مؤسسية كافية بقاعدة البيانات وPL/SQL، يبدو هذا حلاً معقولاً.ضع في اعتبارك مجموعات الدُفعات الكبيرة، حيث إن كل استدعاء من PL/SQL إلى محرك SQL الفعلي هو عبارة عن مفتاح تبديل للسياق، لذلك يجب تجميع عمليات السجل الفردية معًا حيثما أمكن ذلك لتحسين الأداء.
فقط تأكد من تسجيل ما يحدث بطريقة أو بأخرى أثناء العمل.وإلا سيكون لديك صندوق أسود، وإذا ظل عالقًا في مكان ما لساعات، فسوف تتساءل عما إذا كان عليك إيقافه أو تركه يعمل "أكثر قليلاً".
PL/SQL هي لغة ناضجة تتكامل بشكل جيد مع SQL.مع كل إصدار من Oracle يصبح أكثر وأكثر قوة.بدءًا من Oracle 11 أيضًا، يتم تجميع PL/SQL إلى كود الجهاز افتراضيًا.
لقد كتبت عددًا كبيرًا من برامج المعالجة المجمعة وإنشاء التقارير في كل من PL/SQL وProج لمشروع واحد.لقد فضلوا عمومًا أن أكتب بلغة PL/SQL حيث وجد مطوروهم الذين سيحافظون عليها في المستقبل أن ذلك أسهل في الفهم من Proكود ج.
انتهى الأمر إلى كونها مجرد معالجة أو تقارير غير تقليدية حقًا تمت كتابتها في Pro * C.
ليس من الضروري كتابتها كإجراءات مخزنة كما ألمح إليها أشخاص آخرون، يمكن أن تكون مجرد ملفات نصية يتم تشغيلها حسب الضرورة، مثل برنامج نصي Shell.اجعل التحكم في مراجعة كود المصدر والانتقال بين أنظمة الاختبار والإنتاج أمرًا أسهل كثيرًا أيضًا.
طالما أن الحسابات التي تحتاج إلى إجرائها يمكن التقاطها بشكل مناسب وسهل القراءة في PL/SQL، فإن استخدام PL/SQL فقط هو الأكثر منطقية.
المصيد الحقيقي هو قابلية الصيانة - من السهل جدًا كتابة SQL غير قابل للصيانة، فقط لأن كل RDBMS لديه بناء جملة مختلف ومجموعة وظائف مختلفة بمجرد الخروج من SQL DML البسيط، ولا توجد معايير حقيقية للتنسيق.التعليق، الخ.
لقد قمت بإنشاء برامج دفعية باستخدام C# و SQL.
إيجابيات لغة C#:
لديك المكتبة الكاملة لـ .NET وكل قوة لغة OO.
سلبيات لغة C#:
*برنامج الدفعات وقاعدة البيانات منفصلان - وهذا يعني أنه سيتعين عليك إدارة برنامج الدفعات الخاص بك بشكل منفصل عن قاعدة البيانات.
* أنت بحاجة إلى الهروب من كل رمز Dang SQL.
إيجابيات SQL:
* يتكامل بشكل جيد مع نظام إدارة قواعد البيانات.إذا كانت هذه المهمة تتعامل مع قاعدة البيانات فقط، فسيكون من المنطقي تضمينها في قاعدة البيانات.وينتهي بك الأمر بقاعدة بيانات واحدة وجميع مكوناتها في حزمة واحدة.
* لا حاجة للهروب من كود SQL
* إبقائها حقيقية - أنت تقوم بالبرمجة في مجال مشكلتك
سلبيات SQL:
إنها SQL وأنا شخصيًا لا أعرفها جيدًا مثل SQL.
بشكل عام، سألتزم باستخدام SQL بسبب الإيجابيات الموضحة أعلاه.
هذا سؤال محمّل :) هناك بعض تصميمات هندسة برمجة قاعدة البيانات التي يجب أن تعرفها ، وما هي تكاليفها/فوائدها.المستوى 2 يعني عمومًا أن لديك عميلًا يتصل بقاعدة بيانات، ويصدر مكالمات SQL مباشرة.المستوى 3 يعني عمومًا أن لديك "خادم تطبيق" يُصدر مكالمات SQL مباشرة إلى قاعدة البيانات، لكن العميل يتحدث إلى خادم التطبيق.بشكل عام، يتيح هذا "التوسيع".أخيرًا، لديك تطبيقان ونصف المستوى يستخدمان تنسيقًا يشبه المستوى الثاني، ويتم تقسيم العمل فقط ضمن الإجراءات المخزنة.
تبدو عمليتك وكأنها نوع من "المكتب الخلفي"، ويحتاج العملاء/العمليات فقط إلى النتائج التي يتم تجميعها وتخزينها مؤقتًا على أساس مرة واحدة شهريًا.أي أنه لا يوجد وكيل يتصل، ويتصل كثيرًا، ويقول "قم بهذه الحسابات".بدلاً من ذلك، فإنك تلمح إلى عملية تحدث من حين لآخر، ويمكنك الهروب من الوقت غير الحقيقي.
لذلك، في ضوء هذه المتطلبات، أود أن أقول أنه بشكل عام، سيكون من الأسرع أن تكون أقرب إلى البيانات، وأن تدع خادم SQL يقوم بجميع الحسابات.أعتقد أنك ستجد أن القرب من البيانات سيخدمك جيدًا.
ومع ذلك، أثناء إجراء هذه الحسابات، قد تجد أن بعض الحسابات غير قابلة لخوادم SQL.خذ على سبيل المثال حساب الفائدة المستحقة للسند، أو أي أداة ذات دخل ثابت.ليست جميلة جدًا في SQL، وأكثر ملاءمة للغة برمجة أكثر ثراءً.ومع ذلك، إذا كان لديك فقط متوسطات بسيطة ومجاميع أخرى معقولة نسبيًا، سألتزم بالإجراءات المخزنة من جانب SQL.
لذا مرة أخرى، لا توجد معلومات كافية فيما يتعلق بطبيعة حساباتك، أو ما يفرضه منزلك فيما يتعلق بقدرات SQL للمطورين للحصول على الدعم، أو ما يقوله رئيسك في العمل... ولكن بما أنني أعرف طريقتي في التعامل مع SQL، وأحب ذلك البقاء على مقربة من البيانات، وسأظل نقيًا في إجراءات SQL/المخزنة لمهمة مثل هذه.
YMMV :)
إنها ليست عادةً أكثر تعبيرًا لأن معظم لغات الإجراءات المخزنة سيئة التصميم.ولكن من المحتمل أن يعمل بشكل أسرع من أي تطبيق خارجي.
أعتقد أن الأمر يتلخص في مدى معرفتك بـ PL/SQL، وكم من الوقت لديك لكتابة هذا، ومدى أهمية الأداء، وما إذا كان بإمكانك أن تتوقع بشكل معقول أن يكون المشرفون على دراية كافية بـ PL/SQL للحفاظ على برنامج كبير مكتوب بلغة PL/SQL. هو - هي.
إذا لم تكن السرعة ذات صلة وكان المشرفون على الأرجح لا يتقنون PL/SQL، فقد يكون من الأفضل استخدام لغة "تقليدية".
يمكنك أيضًا استخدام نهج مختلط، حيث تستخدم PL/SQL لإنشاء بيانات وسيطة (على سبيل المثال، روابط الجداول والمجاميع أو أي شيء آخر) وتطبيق منفصل للتحكم في التدفق والتحقق من القيم والأخطاء.
