يعد استعلام الترحيل مشكلة شائعة جدًا. دعونا نلقي نظرة أولاً على سبب وجود استعلام الترحيل:
راحة المستخدم: من المستحيل على المستخدمين عرض جميع البيانات مرة واحدة، لذلك من الأفضل تصفح الصفحة تلو الأخرى.
تحسين الأداء: سيكون جلب كافة البيانات من قاعدة البيانات مرة واحدة أبطأ.
والآن اسمحوا لي أن أحاول دحض الأسباب المذكورة أعلاه:
هل هذا مناسب حقًا؟ نحن نأخذ في الاعتبار الموقف التالي إذا كان هناك 20 قطعة فقط من البيانات.
إذا تجاوزت البيانات 1000 عنصر.
من الواضح أن النوع الأول لا يتطلب استعلامات الترحيل. والغريب في الأمر أن الخيار الثاني ليس ضروريًا، لأنه لا يوجد مستخدم على استعداد لقلب صفحة تلو الأخرى حتى النهاية. إذا تجاوزت البيانات التي يستفسر عنها المستخدم نطاق البيانات الذي يهتم به، أعتقد أنه يجب السماح له بإعادة الإدخال شروط الاستعلام، تمامًا مثلنا مثل استخدام Google.
ولكن كواجهة تطبيق سهلة الاستخدام، نأمل دائمًا أن يتمكن المستخدم من فهم نتائج استعلامه بشكل كامل، لذلك من الضروري إخبار المستخدم: "ما مقدار البيانات التي وجدتها؟ ومع ذلك، حاليًا يمكن عرض أول 1000 عنصر فقط. إذا تريد عرض كافة البيانات، ثم ما يجب القيام به..."
هل سيتحسن الأداء؟
إذا كانت كمية البيانات صغيرة، فمن الواضح أن الأداء لن يتحسن بشكل ملحوظ، بل على العكس، سيتم تقليل الأداء بشكل كبير. لأن قاعدة البيانات تنفذ استعلامات وشروط استعلام غير ضرورية.
إذا كانت كمية البيانات كبيرة، فقد لا يتحسن الأداء بشكل ملحوظ، لأنه يتعين عليك دائمًا تنفيذ استعلام عدد إضافي، وعند دمج SQL، من المحتمل جدًا أن يتسبب ذلك في إجراء فحص كامل للجدول. بالطبع، هذا يعتمد على مبدأ تنفيذ قاعدة البيانات.
يمكن تخيل أن العلاقة بين تأثير استعلامات الترحيل على الأداء وكمية البيانات يجب أن تكون منحنى، عندما تكون كمية البيانات صغيرة، سينخفض الأداء، وعندما تكون كمية البيانات كبيرة، سيتم تقليل الأداء قد يتم تحسينها (اعتمادًا على قواعد بيانات مختلفة). المفتاح هو العثور على نقطة انعطاف المنحنى من خلال الاختبار. لا يتم الحصول على الأداء بناءً على الخبرة والشعور، ولكن من خلال الاختبار، بالإضافة إلى ذلك، إذا تم إخراج جميع البيانات مرة واحدة، فسيؤثر ذلك بالفعل على أداء المساحة. ومع ذلك، أصبحت الذاكرة رخيصة جدًا الآن.
التأثير السلبي بالنسبة لتطبيق ويب جيد التصميم، من غير المريح حقًا تمرير pageNo وPageSize بين الفئات المختلفة، ومن الواضح أن هاتين البيانات تنتميان إلى طبقة العرض التقديمي. بالطبع، إذا كنت تستخدم RoR، لم أذكر ذلك.
يزيد بشكل كبير من تعقيد البرمجة، خاصة عند النظر في استقلالية قاعدة البيانات.
ظاهرة غريبة: لماذا لا توفر قاعدة البيانات الكبيرة استعلامات الترحيل مباشرة؟ لا يتم استخدام RowNo الخاص بـ Oracle للترحيل، ولا يتم استخدام Top الخاص بـ SQLServer.
ختاماً
يوفر كل من ExtremeTable وDisplayTag وJSF DataTable طرقًا بسيطة للترحيل، أي الترحيل في مجموعة النتائج. إنه مناسب جدًا للاستخدام ويجعل المنطق واضحًا، مما يحسن كفاءة العمل بشكل كبير. في معظم الحالات، يمكن استخدام هذه الطريقة مباشرة.
إذا وجدت من خلال الاختبار أن الطريقة المذكورة أعلاه تؤثر على الأداء، ففكر في استخدام استعلامات الترحيل.
بالنسبة للتطبيقات التي تضم عددًا كبيرًا من المستخدمين، يمكن أيضًا أخذ استعلامات الترحيل في الاعتبار بسبب قيود الذاكرة. ومع ذلك، أنا شخصيا أوصي بطريقة التخزين المؤقت: يتم وضع نفس الاستعلام في ذاكرة التخزين المؤقت ...
استخدم تصميمًا معقولًا لحماية المطورين من التعامل مع منطق الترحيل. على سبيل المثال، يتم وضع منطق الترحيل واستعلام العدد في الفئة الأصلية، ويكون المطور مسؤولاً عن دمج شروط الاستعلام. دعونا نلقي نظرة على أنماط التصميم على وجه التحديد.
الجميع مدعوون للمناقشة! ! !