سؤال

في الأيام الخوالي ، اعتدنا على الوصول إلى قاعدة البيانات من خلال الإجراءات المخزنة. كان يُنظر إليهم على أنهم "أفضل" لإدارة البيانات. نحتفظ بالبيانات في قاعدة البيانات ، ويمكن لأي لغة/منصة الوصول إليها من خلال JDBC/ODBC/etc.

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

بدأت في التخطيط لمشروع كبير لتخزين البيانات يستخدم J2EE ، لكنني غير متأكد قليلاً مما إذا كنت سأذهب إلى الإجراءات المخزنة أو JDO/JPA وما شابه. في الآونة الأخيرة ، كنت أعمل مع السبات ، ولكي أكون صادقًا تمامًا ، لا أفتقد كتابة الإجراءات المخزنة CRUD!

يتلخص بشكل أساسي في:

الإجراءات المخزنة
+ يمكن تحسينها على الخادم (على الرغم من الاستفسارات فقط)
- من المحتمل أن يكون هناك أكثر من ألف إجراء مخزن: إضافة ، حذف ، تحديث ، getbyid ، إلخ ، لكل جدول.

JDO
+ لن أقضي الأشهر القليلة المقبلة في كتابة المعلمات. add ("@firstNames" ، customer.getFirstName ()) ؛ ...
- سيكون أبطأ من SPS (ولكن معظم الدعم ترحيل)

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

شكرًا،

يوحنا

لا يوجد حل صحيح

نصائح أخرى

"JDO - سيكون أبطأ من SPS (ولكن معظم الدعم ترحيل)"

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

يتميز مستودع البيانات بأحمال إدراج فقط وطويل الأمد SELECT...GROUP BY... استفسارات.

أنت لا تكتب معالجة المعاملات OLTP. أنت لا تستخدم 3NF كوسيلة لمنع تحديث الحالات الشاذة في المعاملات التحديث/الحذف.

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

بما أنك تفعل في الغالب SELECT GROUP BY, ، لن يساعد SP كثيرًا هنا ، أيضًا. لا يستفيد عبارة SELECT من الالتفاف في الإجراء.

أنت لا تحتاجهم. لا يساعدون.

يمكنك بسهولة قياس الحمل بالجملة والاستعلام لإثبات أن SP لا يساعد.

كتب رود جونسون في فيلم "J2EE Design ADN Development" تحليلًا واضحًا للغاية حول ORM/storedprocedures. هو قال ذلك

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

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

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

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

مرخصة بموجب: CC-BY-SA مع الإسناد
لا تنتمي إلى StackOverflow
scroll top