|
Đang cùng đọc chủ đề này:
không có ai
|
|
Tên Login  | |
|
[Thảo luận] Phân trang tối ưu nhất ? - 4/13/2009 10:53:50 AM
|
|
|
MrX
Bài viết đã đăng: 22
Điểm: 0
Ghi ngày: 4/2/2007
Tình trạng: offline
|
Cách phân trang nào tối ưu nhất? Tôi thường dùng temp table để phân trang. Không rõ cách này có hiệu quả với dữ liệu lớn không? Các bác đang dùng cách phân trang nào?
|
|
|
|
|
RE: [Thảo luận] Phân trang tối ưu nhất ? - 4/17/2009 9:05:55 AM
|
|
|
MrX
Bài viết đã đăng: 22
Điểm: 0
Ghi ngày: 4/2/2007
Tình trạng: offline
|
cái này tôi có đọc rồi. Đang bảo là thảo luận xem mọi người hay sử dụng cách phân trang nào mà, chứ đâu phải là tôi ko biết đâu
|
|
|
|
|
RE: [Thảo luận] Phân trang tối ưu nhất ? - 6/11/2009 1:25:37 AM
|
|
|
itshare277
Bài viết đã đăng: 718
Điểm: 0
Ghi ngày: 4/25/2009
Đến từ: P e a r l l a n d
Tình trạng: offline
|
Chả có cách nào tối ưu đâu. Cái gì cũng có cái ưu và nhược điểm của nó thôi.
Ví dụ: Nếu phân trang trong DB thì khi dữ liệu tải về và phân trang nhanh hơn. Nhưng thay vào đó, tài nguyên trên Server bị chiếm dụng nhiều hơn. Ngược lại, nếu download hết về rồi phân trang thì ngồi chờ dài cổ. Server vẫn hoạt động bình thường
_____________________________
Fate stay night!
|
|
|
|
|
RE: [Thảo luận] Phân trang tối ưu nhất ? - 6/16/2009 2:58:55 PM
|
|
|
akenpc
Bài viết đã đăng: 6
Điểm: 0
Ghi ngày: 8/22/2008
Tình trạng: offline
|
tớ chưa hiểu tại sao phân trang trong DB thì tài nguyên trên server bị chiếm dụng nhiều hơn là thế nào, tớ tưởng khi có đc dữ liệu trả về thì nó giải phóng bộ nhớ trên server rui chứ nhỉ , còn nếu load dữ liệu nhiều thì mới chiếm tài nguyên nhiều vì thời gian thao tác lâu sử lí không tốt rất dễ bị dead log (tớ hiểu thế)
|
|
|
|
|
RE: [Thảo luận] Phân trang tối ưu nhất ? - 1/26/2010 10:59:37 PM
|
|
|
0nce_Click
Bài viết đã đăng: 43
Điểm: 0
Ghi ngày: 6/11/2008
Tình trạng: offline
|
Có thể so sánh việc phân trang trong DB và trong code behind như việc so sánh Thông dịch và Biên dịch code vậy.
Phân trang trong DB là sự làm việc không đồng bộ, tức là vừa tải về vừa hiển thị kết quả, trong khi phân trang trong code behind cần tải toàn bộ dữ liệu về sau đó mới tính toán hiển thị cái gì, phân thành bao nhiêu trang.
Với 2 cách làm đó thì ai nhìn cũng có thể biết sử dụng tốt xấu ra sao. Cũng như tại sao các Compiler lại phải nâng cấp từ Thông dịch thành Biên dịch vậy.
_____________________________
0nce_Click
|
|
|
|
|
RE: [Thảo luận] Phân trang tối ưu nhất ? - 1/27/2010 12:47:25 AM
|
|
|
MrSlowly
Bài viết đã đăng: 1126
Điểm: 4
Tình trạng: offline
|
quote:
Trích đoạn: 0nce_Click
Có thể so sánh việc phân trang trong DB và trong code behind như việc so sánh Thông dịch và Biên dịch code vậy.
Phân trang trong DB là sự làm việc không đồng bộ, tức là vừa tải về vừa hiển thị kết quả, trong khi phân trang trong code behind cần tải toàn bộ dữ liệu về sau đó mới tính toán hiển thị cái gì, phân thành bao nhiêu trang.
Với 2 cách làm đó thì ai nhìn cũng có thể biết sử dụng tốt xấu ra sao. Cũng như tại sao các Compiler lại phải nâng cấp từ Thông dịch thành Biên dịch vậy.
Hoàn toàn không hiểu :-??
Phân trang tại DB - Thường thì sẽ áp dụng kỹ thuật phân trang bằng store procedure ( cả 3 loại db phổ biến trong lập trình ứng dụng hiện nay: MySQL- limit,MS SQL,Oracle đều hỗ trợ) . Với việc này thì sẽ tiết kiệm tài nguyên rất nhiều. Nếu bạn cần hiển thị 10 bản ghi của trang thứ nhất thì bạn chỉ cần truyền vào số bản ghi cần lấy ( Thông qua các Parameter: CurrPage(trang hiện tại), PageSize( Số bản ghi trên một trang) kèm theo diều kiện truy vấn nếu có. Thì DB chỉ lấy ra 10 bản ghi bạn cần. Việc lấy ra 10 bản ghi sẽ được tính toán tại DB, còn thực chất ở bên trên Giao diện ( UI) chỉ tiến hành thủ tục để hiển thị 10 bản ghi đó ( kèm theo các hyperlink để người dùng lựa chọn các trang kế tiếp - Chính là tổng số bản ghi thỏa điều kiện tìm kiếm)
Với cách phân trang này webserver sẽ đỡ phải xử lý hơn nhiều ( Nếu phân trang tự động = Control như DataGrid hay GridView thì sẽ lấy tất cả các bản ghi thỏa đk tìm kiếm sau đó sẽ căn cứ vào trang được gọi, nó cũng sẽ lấy ra N bản ghi để hiển thị)
Như vậy thì rõ ràng trong trường hợp phân trang tiến hành ở UI thì Chúng ta sẽ phải mất nhiều công, chi phí để làm một số việc ko cần thiết trước khi được việc cần thiết
Cụ thể: tôi muốn triệu tập 10 thằng có thứ tự trong danh sách lớp từ 10 đến 19 để ngồi ngồi nhậu tất niên. Thay vì tôi bảo thằng lớp trưởng là đưa cho tôi những thằng có thứ tự từ 10 đến 19, tôi sẽ bảo thằng lớp trưởng gọi tất cả những thằng thuộc danh sách lớp đó. Sau đó tự tôi đếm và tính toán xem thằng nào có thứ tự là 10, lấy từ nó tới thằng thứ 19 để cho đủ 10 thằng ( giả sử danh sách lớp có 100 thằng) - như vậy rõ ràng tôi đã làm một việc thừa là tôi gọi những thằng từ 0-9 và từ 20-99 một cách vô ích. Đáng ra tôi chỉ bảo những thằng từ 10 đến 19 ra là OK.
Ví dụ trên cũng giống như việc phân trang bằng control ( Datagrid,Gridview) với việc phân trang bằng store procedure.
_____________________________
--------
Điều lệ của box ASP.NET http://forum.aspvn.net/tm.aspx?m=792
--------
Mailto: conso0vidai@yahoo.com
Y!M : conso0vidai
|
|
|
|
|
RE: [Thảo luận] Phân trang tối ưu nhất ? - 2/1/2010 3:57:37 PM
|
|
|
dammio
Bài viết đã đăng: 433
Điểm: 20
Ghi ngày: 12/12/2008
Đến từ: Flower City
Tình trạng: offline
|
Việc phân trang này đã chốt lại từ rất nhiều bài viết của forum. Bạn search lại tìm nhé.
Hi vọng năm mới chúng ta có thêm nhiều phương pháp phân trang hay nữa.
_____________________________
D A M M I O in yeusangtao.com
|
|
|
|
|
RE: [Thảo luận] Phân trang tối ưu nhất ? - 3/4/2010 8:49:00 PM
|
|
|
itshare277
Bài viết đã đăng: 718
Điểm: 0
Ghi ngày: 4/25/2009
Đến từ: P e a r l l a n d
Tình trạng: offline
|
Thực ra hồi giờ chúng ta chỉ nắm 2 vấn đề chính đó là:
1. Phân trang thực hiện tại phía Server Side thông qua Store Procedure.
2. Phân trang tại phía Client Side, thực hiện tại Code behind. Chỗ này đã được cải tiến bằng cách: Nếu dữ liệu của Server chưa Update một record nào đó thì ta có thể tiến hành Set cache cho nó, và chúng ta phân trang dựa trên Data có trong Cache, sẽ nhanh hơn chút ít vì không phải thực hiện Query Execute.
_____________________________
Fate stay night!
|
|
|
|
|
RE: [Thảo luận] Phân trang tối ưu nhất ? - 5/15/2010 7:01:30 PM
|
|
|
colauhong
Bài viết đã đăng: 107
Điểm: 3
Ghi ngày: 5/15/2010
Đến từ: Đà Lạt
Tình trạng: offline
|
Theo ý của em thì thế này:
Ví dụ ta có 100 dòng cần phân trang, với mỗi trang 10 dòng thì mặc định ta yêu cầu server cho ta 10 dòng đầu tiên
Sau đó khi yêu cầu trang trang nào thì load tương ứng.
Tôi biết là sử dụng cách này sẽ yêu cầu nhiều lần nhưng tui thích cách này
Phương pháp làm cụ thể và nhanh nhất là sử dụng 2 control GirdView và LinqDatasource khỏi code 
_____________________________
Chuyên xây dựng và thiết kế Website theo chuẩn.
Nhận tham gia dự án, nhóm phát triển trên nền dotNet
- Liên hệ:
1.YM!: lengoctuan_dl
2.Phone: 0917.427342
3.E-Mail: lengoctuan.dl@gmail.com
.: I love csharp :.
== Mỗi ngày một công nghệ ==
|
|
|
|
|
RE: [Thảo luận] Phân trang tối ưu nhất ? - 5/26/2010 10:53:05 AM
|
|
|
dammio
Bài viết đã đăng: 433
Điểm: 20
Ghi ngày: 12/12/2008
Đến từ: Flower City
Tình trạng: offline
|
Phương pháp dùng ROW_NUMBER() vẫn là phương pháp khá nhất hiện nay trên SQL 2005.
Phải chờ vài năm nữa mới xem ai có khả năng phát minh cách mới. Thảo luận này đã được lặp lại quá nhiều!
_____________________________
D A M M I O in yeusangtao.com
|
|
|
|
|
RE: [Thảo luận] Phân trang tối ưu nhất ? - 7/4/2010 11:54:13 PM
|
|
|
caominhtuy
Bài viết đã đăng: 36
Điểm: 2
Ghi ngày: 5/13/2010
Tình trạng: offline
|
Theo mình thì như thế này:
- Đối với database lớn có thể lên tới hàng 1000 bản ghi hoặc lớn hơn thì việc phân trang bằng storeprocedure là khả thi nhất.
- Đối với những database vừa phải thì việc phân trang bằng control thì có vẻ hợp lý hơn.
Đây là ý của mình có ji` mong mọi người bổ sung thêm
Thank!
|
|
|
|
|
 Bài Mới |
 Không Có Bài Mới |
 Chủ đề nóng và CÓ bài viết mới |
 Chủ đề nóng và KHÔNG có bài viết mới |
 Đã khóa và CÓ bài viết mới |
 Đã khóa và KHÔNG có bài viết mới |
|
 Đăng Đề Mục Mới
Trả Lời
Trưng Cầu
Ý Kiến Của Bạn
Delete My Own Post
Delete My Own Thread
Đánh giá bài |
|
|
| Quảng cáo - Liên kết |
|
 |
|
Printable Version
