سوالی در مورد Custom Paging و بالا بردن Performance آن....

[white fox]

با سلام...
نمیدونم بخشم رو درست انتخاب کردم یا نه چون سوال بیشتر SQL هست تا ASP.NETی اما بدین خاطر پرسیدم در اینجا که حتما دوستان برنامه نویس به این مشکل بیشتر برخورد کردن.
امیدوارم مدیران بخش اشکالی از این سوال نگیرند.
دوستان عزیز من در اکثر جاهایی که جستجویی انجام دادم در مورد Custom Paging تقریبا 90 درصد اونها راه حلی شبیه به هم داشتند و روش هم این بود که اطلاعات جدولی که میخوایم روش عمل Paging رو انجام بدیم رو قرار میدادند توی یک جدول موقت که یک ستون Identity داشت که باعث میشد هر سطری یک شماره بگیره
حالا بر اساس اون ستون میومدن با گرفتن چند پارامتر تعداد رکورد مربوطه رو از جدول میکشیدن بیرون...
اما مشکلی که اینجا هست اینه که ما باید بدونیم کدوم جداول رو میخوایم باهاش عمل Paging رو انجام بدیم...
حالا فرضا ما میخوایم برای تعداد بیشتری این کار رو انجام بدیم مثلا 6 یا بیشتر...آیا باید برای هر کدوم یک SP جدا بنویسیم؟

من خودم روشی که انجام دادم این بود که دستور SELECT مربوطه رو که در واقع هدف نام جدول هست رو به SP ارسال میکنم و با دستور EXEC یک جدول میسازم و اطلاعات این جدول ارسالی رو داخلش میریزم...
اما خوب نمیشه دیگه اینجا از جدول موقتی استفاده کرد من مجبور شدم یک جدول دائمی بسازم
از طرفی هم چون هر بار ممکنه جدول متفاوتی ارسال بشه نمیشه جدول رو ساختارش رو نگه داشت یعنی از Truncate یا DELETE برای حذف داده ها نمیشه استفاده کرد و حتما باید جدول پاک بشه و با ارسال بعدی ایجاد...
خوب به نظر خودم این روش روش بهینه ای نیست که هر بار که درخواستی از سوی این جداول صورت میگیره جدول مدام پاک و ایجاد بشه...
چون این سایتی که من دارم براش برنامه مینیویسم همین حالا چیزی حدود 200 تا 300 بیننده در روز داره و پیش بینی میکنیم با ساخت سایت جدید و امکاناتش سریعا به روزی 500 نفر به بالا برسه...
شما دوست عزیزی که تجربتون در طراحی بیشتر شما از چه روشی برای حل این مشکل استفاده میکنید؟
آیا بهتره برای هر 6 جدول جدا SP بنویسم؟
از راهنماییتون بی نهایت ممنونم.

[manager]

سلام دوست من

قبل از اینکه روش رو توضیح بدم بهتره از شما بپرسم حجم اطلاعاتی رو که شما در یه جدول نگه می دارید چه قدره ؟
اگر این حجم کمتر از تقریبا 1000 تا رکورد باشه بهترین روش و آسون ترین روش استفاده از همون روش Row_Number می باشد.
اما اگر حجم اطلاعاتتون بیشتر از این مقداره باید از روش بهینه تر و سریع تری استفاده کنید حتی اگر مجبور باشید برای 10-15 جدول شبیه به هم SP بنویسید. یادتون باشه ما SP می نویسیم که سرعت بازیابی اطلاعات بره بالا چون همون طور که خودتون هم می دونید SqlServer کدهای SP شما رو Precompile می کنه در نتیجه خیلی سریع تر اون ها رو اجرا می کنه ..
استفاده از EXEC هیج فرقی با TextCommand نداره و SQL مجبوره با هر بار اجرای این سری دستورات اون ها رو مجددا از نوع Compile کنه..
یکی از بهترین و سریع ترین روش هائی که من استفاده کردم استفاده از Top x و اخرین ID می باشد. این روش سرعت بسیار زیادی داره و پیاده سازیش هم خیلی آسونه, تنها مشکلی که داره عدد x یا اندازه پیج هاست که ثابته و نمی تونید تغییرش بدید.
روش های دیگه ای هم وجود داره که از ترکیب این روش می شه به دست آورد مثلا صفحات 10 تائی می تونید بگید 3 تا صفحه 10 تائی بده یا 1 دونه صفحه 10 تائی بده و یا این که تعداد صفحات رو به 5 ,2 و حتی 1 کاهش بدین..هرچی باشه به نظر من استفاده از روش های مذکور بهتر از کپی کردن 3000 تا رکورد تو یه جدول موقتیه ...

[white fox]

ممنون از توجه شما دوست عزیز..امیدوارم بقیه دوستان هم کمک کنند در این بحث
پس نظر شما هم اینه که بهتره برای هر جدول SP جدا بنویسیم؟...
البته منم نظرم همینه چون مطمئنم ظرف چند ماه اطلاعات زیاد خواهد شد و همینطور کاربرها..
و اصلا منطقی نیست تعدا زیادی رکورد به همراه خود جدول مدام ساخته بشه چون به صورت فیزیی هم ساخته میشه..
من خودم فکر کردم برای اضافه کردن اون ستون IDENTITY هم بجای جدول موقتی از Table Variable استفاده کنم....فکر میکنم این طوری بهتر باشه...
نظر شما چیه؟
امیدوارم بقیه دوستان مخصوصا مدیران مثل آقای راد هم کمک کنن..

[BigBrother]

من توی پروژه اخیرم که با asp.net 2.0 نوشته ام دو جور Paging رو امتحان کردم!!یکی Paging :نترل GridView و دیگری Paging Custom با همون روش قدیمی جدول موقت!!متاسفانه یا خوشبختانه به طور تعجب انگیزی پرفورمنس Paging خود کنترل سریع تر به نظر میرسه!!
کسی میتونه این موضوع رو توجیح کنه؟!
(این مسئله با 5000 رکورد تست شده)