Permintaan halaman adalah masalah yang sering ditemui. Mari kita lihat dulu alasan mengapa permintaan halaman ada:
Kenyamanan pengguna: Tidak mungkin bagi pengguna untuk melihat semua data sekaligus, jadi lebih baik menelusuri halaman demi halaman.
Meningkatkan kinerja: Mengambil semua data dari database sekaligus akan lebih lambat.
Jadi sekarang izinkan saya mencoba menyangkal alasan di atas:
Apakah ini benar-benar nyaman? Kami mempertimbangkan situasi berikut jika hanya ada 20 buah data.
Jika data melebihi 1000 item.
Tipe pertama jelas tidak memerlukan query paging. Yang aneh adalah yang kedua tidak diperlukan, karena tidak ada pengguna yang mau membalik halaman demi halaman sampai akhir. Jika data yang ditanyakan pengguna melebihi rentang data yang dia pedulikan, saya pikir dia harus diizinkan masuk kembali syarat querynya, sama seperti kita Sama seperti menggunakan google.
Namun sebagai antarmuka aplikasi yang ramah, kami selalu berharap pengguna dapat memahami sepenuhnya hasil kuerinya, sehingga perlu untuk memberi tahu pengguna: "Berapa banyak data yang Anda temukan? Namun, saat ini hanya 1.000 item pertama yang dapat ditampilkan. Jika Anda ingin melihat semua Data, lalu apa yang harus dilakukan..."
Apakah kinerja akan meningkat?
Jika jumlah datanya sedikit, jelas performanya tidak akan meningkat secara signifikan. Karena database melakukan kueri dan kondisi kueri yang tidak diperlukan.
Jika jumlah datanya besar, kinerjanya mungkin tidak meningkat secara signifikan, karena Anda selalu harus menjalankan kueri jumlah tambahan, dan saat menggabungkan SQL, kemungkinan besar akan menyebabkan pemindaian tabel penuh. Tentu saja, hal ini tergantung pada prinsip implementasi database.
Dapat dibayangkan bahwa hubungan antara dampak kueri paging terhadap kinerja dan jumlah data harus berbentuk kurva. Jika jumlah datanya kecil, kinerjanya akan berkurang, dan ketika jumlah datanya besar, kinerjanya mungkin (tergantung pada database yang berbeda) ditingkatkan. Kuncinya adalah menemukan titik belok kurva melalui pengujian. Performanya tidak didapat berdasarkan pengalaman dan perasaan, melainkan melalui pengujian. Selain itu, jika semua data dikeluarkan sekaligus memang akan mempengaruhi performa ruang.
Dampak negatif Untuk aplikasi web yang dirancang dengan baik, sangatlah tidak nyaman untuk meneruskan pageNo dan PageSize di antara berbagai kelas. Kedua data ini jelas merupakan bagian dari lapisan presentasi. Tentunya jika Anda menggunakan RoR, saya belum menyebutkannya.
Secara signifikan meningkatkan kompleksitas pemrograman, terutama ketika mempertimbangkan independensi database.
Fenomena aneh: Mengapa database besar tidak langsung menyediakan permintaan paging? RowNo Oracle tidak digunakan untuk paging, begitu pula Top SQLServer.
sebagai kesimpulan
ExtremeTable, DisplayTag, dan JSF DataTable semuanya menyediakan metode paging sederhana, yaitu paging dalam kumpulan hasil. Sangat nyaman digunakan dan membuat logikanya jelas, sehingga sangat meningkatkan efisiensi kerja. Dalam kebanyakan kasus, metode ini dapat digunakan secara langsung.
Jika melalui pengujian Anda menemukan bahwa metode di atas memengaruhi kinerja, pertimbangkan untuk menggunakan kueri paging.
Untuk aplikasi dengan jumlah pengguna yang besar, permintaan paging juga dapat dipertimbangkan karena keterbatasan memori. Namun, saya pribadi merekomendasikan metode caching: kueri yang sama ditempatkan di cache...
Gunakan desain yang masuk akal untuk melindungi pengembang dari berurusan dengan logika paging. Misalnya, logika paging dan kueri penghitungan ditempatkan di kelas induk, dan pengembang bertanggung jawab untuk menggabungkan kondisi kueri. Mari kita lihat pola desain secara spesifik.
Semua orang dipersilakan untuk berdiskusi! ! !