PDA

View Full Version : یه مشکل با pagination و فیلتر کردن اطلاعات



leaping
جمعه 14 فروردین 1394, 17:24 عصر
سلام
میخواستم بدونم که فرض کنید یه جدول هست شامل هزاران رکورد اطلاعات و حالا میخوایم صفحه بندی کنیم.تا اینجای کار صفحه بندی مشکلی نداره
از اونجایی مشکل درست میشه بخوایم اطلاعات رو بر اساس یک سری اطلاعات از داخل یک دیتابیس دیگه و یا از سوی کاربر فیلتر کنیم.
خب در این حالت مثلا داریم از LIMIT 0,20 استفاده میکنم توی کوری واسه فراخوانی صفحات مختلفمون
خب در این حالت داریم 20 تا رکورد رو با حلقه واکشی میکنیم و هر صفحه هم اینطوری میشه مثلا
صفحه یک LIMIT 0,20
صفحه دو LIMIT 20,20
صفحه سه LIMIT 30,20
خب در این حالت اگر بخوایم اطلاعات رو فیلتر کنیم اگه از صفحه یک 5 تا رکورد حذف بشه در صفحه اول 15 تا رکورد نشون داده میشه و تو صفحه دو همون 20 تا , خب این قشنگ نیست. حالا این رو با استفاده از php داخل خود حلقه حل کردم.هرچند قشنگ نیست اما حل شده
اما مشکل از اونجایی شروع میشه که وقتی رکوردها حذف میشن از 20 رکورد اول من کاری کردم که به هر ترتیب تو صفحه اول مثلا 20 تا رکورد نشون داده بشه , خب در این حالت یک سری از رکوردها از صفحه اول توی صفحه دوم بازهم تکرار میشن, خب من نمیخوام اینطوری باشه
همونطور هم که گفتم اطلاعات بر اساس اطلاعات ورودی کاربر و یا از یک دیتابیس دیگه فیلتر میشن و با JOIN تو کوری نمیشه درستش کرد
راه حلی خاصی دارین برای این مورد؟ :D

Unique
جمعه 14 فروردین 1394, 18:45 عصر
قبل از پاسخ بگم که اصلا مهم نیست اطلاعات چطور فیلتر میشن ! حالا چه از جایی دیگه باشه یا کاربر درخواست داده باشه یا هر دو ! موضوع join هم اهمیتی نداره.

یکسری مواردی که شم امیگین مشکوکه :

اگه از صفحه یک 5 تا رکورد حذف بشه در صفحه اول 15 تا رکورد نشون داده میشه و تو صفحه دو همون 20 ت
ابهام داره ! اما استنباط من اینه که شما دارین رکورد ها را توی مرکز کنترل به مدیر نشون میدین و ممکنه توی صفحه دوم مثلا ۴ تا checkbox بگذارین و مدیر با انتخاب رکورد ها دستور حذف بده :
۱ - اگه ajax نیست که خوب شما شماره صفحه فعلی را همراه با درخواست حذف ارسال کنید و بعد از حذف رکورد ها limit را تعین گنید و روی query بگذارین.
۲ - اگه ajax هست باید شماره صفحه جاری را ارسال کنید و در در مقادیر بازگشتی پس از حذف رکورد ها دوباره فهرست صفحه دوم را دریافت کنید.

اگه ۱ درصد هم paging شما به مقادیر ستون ID مرتبط هست (البته غیر از بزرگتر و کوچکتر مرتبط با رکورد اول صفحه بعد و رکورد آخر صفحه قبل که اصلا نمیتونن توی دستور حذف صفحه جاری قرار بگیرن) کلا دارین اشتباه عمل میکنین و شما هیچ نیازی به مقادیر ستون ID ندارین و باید بر اساس صفحه درخواستی مقدار limit r,n را محاسبه کنید.

فکر کنم اگه کد مربوط به query و محاسبات pagination خودتون را بگذارین بشه دقیقتر نظر داد.

leaping
جمعه 14 فروردین 1394, 19:13 عصر
ممنون
خیلی دوس دارم همچین کاری بکنم اما خیلی زیاده هرکی ببینه حوصلش سر میره :D
اما خب به قول شما یکم ابهام داره وایسید توضیح بدم
منظورم از اینکه بر اساس اطلاعات جای دیگه فیلتر انجام میشه منظورم اینه که نمیشه توی کوئری قرارش داد یجوورایی البته دقیق نمیدونم شاید بشه
فرض کنید من یه جدول دارم 200 تا رکورد از کاربرهای مختلف
خب در این حالت فرض کنید این میخواد 10 تا صفحه 20 رکوردی بشه
تا اینجای کار درست و هر 20 یوزر در یک صفحه قرار میگیره بر اساس همون limit

خب بر اساس همین موضوع اگر من بخوام مثلا طبق یک شرط درون حلقه واکشی اطلاعات یک سری رکورد رو از صفحه اول حذف کنم.حذف میشه
خب مشکل اینجاست که حالا صفحه دوم از کجا بفهمه که آخرین رکورد نمایشی تو صفحه اول چی بوده تا بر اساس اون بیاد اطلاعات رو نمایش بده؟
اگر باز نتونستم منظورم رو برسونم بگید یه متن طلانی تر بنویسم

Unique
شنبه 15 فروردین 1394, 10:30 صبح
فکر کنم شما دارین فیلتر را توی بدنه for انجام میدین اما میخواین pagination را بر اساس خروجی query انجام بدین ! خوب معلومه این جواب نمیده. شما یا باید فیلتر را با where یا join یا having بیارین توی query و بر اساس خروجی query و limit نمایش بدین یا اگه میخواین توی بدنه for چیزی را فیلتر کنید. pagination را هم توی همون for انجام بدین. مثلا یک counter بگذارین و برای صفحه دوم مقادیر بعد از ۲۰ را در صورت درست بودن فیلتر شما نمایش بدین. در واقع اصلا نباید توی query از limit استفاده کنید. این روش اصلا بهینه نیست و شما مجبورین برای صفحه ۱۰۰ از اول query را بررسی کنید اما میشه یه کار هایی کرد :

۱ - میتونین به جای استفاده از pagination از prev و next استفاده کنید. در این روش اولین و آخرین رکورد چاپ شده را دارین و مثلا شما میدونین آخرین رکوردی که توی for از فیلتر گذشته و مربوط به صفحه اول هست id ی برابر ۳۴ داره . حالا برای next میتونید توی query رکورد هایی که id اونها بیشتر از ۳۴ هست را نمایش بدین و همین روش اما عکسش برای prev.

۲ - میتونین اطلاعات را cache کنید و وقتی کاربر صفحه تکراری درخواست میکنه دیگه عملیات انجام ندین و مقدار cache شده را نشون بدین.

leaping
شنبه 15 فروردین 1394, 12:58 عصر
بله گفتم که درون یک حلقه واکشی میشه البته حلقه while بعدشم اینکه توضیح دادم که نمیشه درخواستهارو از داخل query فیلتر کرد چون اصلا درون یک دیتابیس و از داخل یک مرجع نیستن و از داخل حلقه فیلتر انجام میشه
بعدشم اینکه counter و اینا گذاشتم.
بعدشم ایننکه نمیخوام صفحه بندیم بر اساس prev و next قالب بندی بشه و میخوام صفحات داشته باشه
یعنی واقعا راهی نیست؟ مگه میشه آخه
یعنی همه وب سایتها میان و از طریق query همه فیلترها رو انجام میدن و بعد داخل حلقه واکشی میکنن؟
از نظر منطقی بعید میدونم کلا اینطوری باشه
و راه هایی هم هست.مثلا اینکه اول بیای از طریق فیلتر کردن اطلاعات کل اطلاعات جدول رو بر اساس id و بر اساس فیلترها تقسیم بندی کنی و متوجه بشی که چه Id هایی مجاز هست و از اون به بعد صفحه بندی رو انجام بدی و هر بار بر اساس اون اطلاعات رو از دیتابیس فراخوانی کنی که البته به نظرم کار زیاد منطقی و بهینه ای نیست.
اما هیچ راه دیگه ای هم به نظرم نمیرسه
یعنی واقعا راه دیگه ای نیست؟

Unique
شنبه 15 فروردین 1394, 14:15 عصر
یعنی همه وب سایتها میان و از طریق query همه فیلترها رو انجام میدن و بعد داخل حلقه واکشی میکنن؟
بله ! راه اصولیش همینه.


از نظر منطقی بعید میدونم کلا اینطوری باشه
اتفاقا منطقیش همون استفاده از database و query هست ! توی حلقه فیلتر کردن و pagination کلا اشتباهه.

اگه من مجبور بودم توی حلقه فیلتر را انجام بدم و pagination را ایجاد کنم از cache استفاده میکردم. همین. شما نمیتونید تقسیم بندی را توی query انجام بدین و توی حلقه خروجی را فیلتر کنید و دردسر هایی که بهش بر خوردین را نداشته باشین.
در برخی شرایط میشه از mysql user defined function ها استفاده کرد و با همون query کار کرد. اما تا سورس کد را نبینم نمیشه قطعا نظر داد.

id1385
شنبه 15 فروردین 1394, 14:33 عصر
کاملاً متوجه نشدم منظورتون از فیلتر چیه ؟
ولی اینطور که برداشت کردم
بهتره شما همون روش صفحه بندی رو انجام بدید و بعد تو خود تیبلی که جهت نمایش اطلاعات هست فیلتر رو انجام بدید (بنا به نیاز مشتری) یعنی سمت یوزر، البته این فیلتر غیر از فیلتریهایی که هست که موقع واکشی انجام میشه

نمونه واکشی و فیلنر اطلاعات موقع کوئری:


$this->_qSql = "SELECT $Cols FROM `$tAble` $SwheRe $sort";



function paginate() {

$dBA->pdoQuery($this->_qSql);


$this->total_rows = $dBA->_recordCount;




//Return FALSE if no rows found
if ($this->total_rows == 0) {
if ($this->debug)
echo "Query returned zero rows.";
return FALSE;
}


//Max number of pages
$this->max_pages = ceil($this->total_rows / $this->rows_per_page);
if ($this->links_per_page > $this->max_pages) {
$this->links_per_page = $this->max_pages;
}


if ($this->page > $this->max_pages || $this->page <= 0) {
$this->page = 1;
}


//Calculate
$this->offset = $this->rows_per_page * ($this->page - 1);


$run = $dBA->pdoQuery($this->_qSql . " LIMIT {$this->offset}, {$this->rows_per_page}")->_qResult;
if (!$run) {
if ($this->debug)
//error
return false;
}
return $dBA->_featch;
}


بعد از اینکه اطلاعات رو صفحه بندی کردید بقیه فیلترها رو میتونید سمت کاربر با کتابخانه های جاوا اسکریپت انجام بدید

موفق باشید

leaping
شنبه 15 فروردین 1394, 21:06 عصر
کاملاً متوجه نشدم منظورتون از فیلتر چیه ؟
ولی اینطور که برداشت کردم
بهتره شما همون روش صفحه بندی رو انجام بدید و بعد تو خود تیبلی که جهت نمایش اطلاعات هست فیلتر رو انجام بدید (بنا به نیاز مشتری) یعنی سمت یوزر، البته این فیلتر غیر از فیلتریهایی که هست که موقع واکشی انجام میشه

نمونه واکشی و فیلنر اطلاعات موقع کوئری:


$this->_qSql = "SELECT $Cols FROM `$tAble` $SwheRe $sort";



function paginate() {

$dBA->pdoQuery($this->_qSql);


$this->total_rows = $dBA->_recordCount;




//Return FALSE if no rows found
if ($this->total_rows == 0) {
if ($this->debug)
echo "Query returned zero rows.";
return FALSE;
}


//Max number of pages
$this->max_pages = ceil($this->total_rows / $this->rows_per_page);
if ($this->links_per_page > $this->max_pages) {
$this->links_per_page = $this->max_pages;
}


if ($this->page > $this->max_pages || $this->page <= 0) {
$this->page = 1;
}


//Calculate
$this->offset = $this->rows_per_page * ($this->page - 1);


$run = $dBA->pdoQuery($this->_qSql . " LIMIT {$this->offset}, {$this->rows_per_page}")->_qResult;
if (!$run) {
if ($this->debug)
//error
return false;
}
return $dBA->_featch;
}


بعد از اینکه اطلاعات رو صفحه بندی کردید بقیه فیلترها رو میتونید سمت کاربر با کتابخانه های جاوا اسکریپت انجام بدید

موفق باشید
با تشکر از پیگیریتون
اما اصلا این قضیه منتفی هست چون منظورم از اینکه توسط کاربر فیلتر بشن یک مثال بود و قصد این هست که سمت سرور این اتفاقات بیوفته و البته بیشتر از اون اینکه قصد ندارم تمام اطلاعات واکشی بشه بلکه میخواهم از همون اول واکشی به صورت محدود انجام بگیره

leaping
شنبه 15 فروردین 1394, 21:09 عصر
بله ! راه اصولیش همینه.


اتفاقا منطقیش همون استفاده از database و query هست ! توی حلقه فیلتر کردن و pagination کلا اشتباهه.

اگه من مجبور بودم توی حلقه فیلتر را انجام بدم و pagination را ایجاد کنم از cache استفاده میکردم. همین. شما نمیتونید تقسیم بندی را توی query انجام بدین و توی حلقه خروجی را فیلتر کنید و دردسر هایی که بهش بر خوردین را نداشته باشین.
در برخی شرایط میشه از mysql user defined function ها استفاده کرد و با همون query کار کرد. اما تا سورس کد را نبینم نمیشه قطعا نظر داد.
منظورم این نبود که این کار منطقی نیست
منظورم این بود از لحاظ منطقی وب سایتهایی وجود دارن که فیلترهاشون تنها مرجعشون خود همون دیتابیس نیست
اصلا اینطوری فرض کنیم که یک مکانیزم فیلتر و شیوه دسترسی با یک کلاس درون برنامه وجود داره و این کلاس میاد فیلترهای نمایش اطلاعات رو در جاهای مختلف اعمال میکنه , خب به این ترتیب قرار نیست که من بیام برای هر قسمت طراحی رو تغییر بدم چون اصلا هم اصولی نیست و هم اینکه دسترسیم برای تغییرات بعدی کم میشه
خب حالا اگه من بخوام اطلاعات رو درون حلقه فیلتر کنم تنها روش همین catch کردن هست؟
اگه بله که ممنون میشم یک ریفرنس بدین ببینم قضیه به چه ترتیب میشه؟

Unique
شنبه 15 فروردین 1394, 23:31 عصر
منظورم این بود از لحاظ منطقی وب سایتهایی وجود دارن که فیلترهاشون تنها مرجعشون خود همون دیتابیس نیست
اصلا اینطوری فرض کنیم که یک مکانیزم فیلتر و شیوه دسترسی با یک کلاس درون برنامه وجود داره و این کلاس میاد فیلترهای نمایش اطلاعات رو در جاهای مختلف اعمال میکنه , خب به این ترتیب قرار نیست که من بیام برای هر قسمت طراحی رو تغییر بدم چون اصلا هم اصولی نیست و هم اینکه دسترسیم برای تغییرات بعدی کم میشه

تجربه به من ثابت کرده که برای فیلتر اطلاعات بهترین روش اینه که کار توی query انجام بشه. کلا شما فیلتر را بر اساس ستون های مرتبط با یک موجودیت اعمال میکنید. مثلا سایت دیجی کالا میاد بر اساس دسته کالا ، نوع کالا ، سازنده کالا ، مدل کالا ، قیمت کالا و مثلا محبوبیت کالا یا تاریخ اضافه شدن به سایت و غیره فیلتر انجام میده. تمام این مشخصه ها برای موجودیت توی پایگاه داده و توی جداول مرتبط به هم وجود داره و هیچ وقت دیجی کالا نمیاد فیلتر را روی خروجی و توی حلقه انجام بده ! راستش را بخوای تا حالا هیچ وقت نیاز نبوده چنین کاری را انجام بدم و هر چی فکر میکنم موردی به ذهنم نمیرسه. مگه اینکه اطلاعات توی پایگاه های داده جدا از هم باشه (که معماری معمولا غلطه مگر اینکه دلیلی قانع کننده ای باشه) یا اصلا اطلاعات توی پایگاه داده نباشه.

در چنین مواردی همونطور که گفتم بهتره pagination توی خود حلقه انجام بشه.

در مورد cache هم کار خارق العاده ای قرار نیست انجام بدین. مثلا کاربر صفحه ۲ را درخواست کرده. وقتی یکبار حلقه را طی کردیم و مقادیر مشخص شده خروجی را توی یک فایل عادی با یک نام منطقی ذخیره میکنیم. مثلا اگه دارین جدول users و صفحه ۲ را cache میکنید میتونید اون را توی www/cache/pagination/users-p2.html ذخیره کنید و دفعات بعد هر وقت کاربر این صفحه را درخواست داد فقط محتویات فایل را بخونیم و براش بفرستیم. توی مرکز کنترل هم هر وقت حذف یا اضافه یا تغییر روی محتوای این صفحه میدیم میتونیم کل فایل هاش را پاک کنیم (با glob راحت میشه با یک دستور این کار را انجام داد) و روز از نو کش از نو ! راه های دیگه هم هست مثلا بر اساس query بیاین cache کنین اما خوب این راهی که گفتم سر راست تره.

اما باز هم میگم اول از همه یک بررسی کامل روی مهندسی پایگاه داده و نرم افزار انجام بدین تا الکی خودتون را درگیر این مباحث نکنید گرچه cache همه جا خوبه اما باید دید آیا واقعا توی performance تاثیری داره !؟ مثلا اگه ۱۰۰۰ تا بازدید در روز بیشتر ندراین نیازی به این کار ها نیست و اصلا به نظر من cache نمیخواد !

حالا تصمیم با شما.

leaping
یک شنبه 16 فروردین 1394, 00:01 صبح
تجربه به من ثابت کرده که برای فیلتر اطلاعات بهترین روش اینه که کار توی query انجام بشه. کلا شما فیلتر را بر اساس ستون های مرتبط با یک موجودیت اعمال میکنید. مثلا سایت دیجی کالا میاد بر اساس دسته کالا ، نوع کالا ، سازنده کالا ، مدل کالا ، قیمت کالا و مثلا محبوبیت کالا یا تاریخ اضافه شدن به سایت و غیره فیلتر انجام میده. تمام این مشخصه ها برای موجودیت توی پایگاه داده و توی جداول مرتبط به هم وجود داره و هیچ وقت دیجی کالا نمیاد فیلتر را روی خروجی و توی حلقه انجام بده ! راستش را بخوای تا حالا هیچ وقت نیاز نبوده چنین کاری را انجام بدم و هر چی فکر میکنم موردی به ذهنم نمیرسه. مگه اینکه اطلاعات توی پایگاه های داده جدا از هم باشه (که معماری معمولا غلطه مگر اینکه دلیلی قانع کننده ای باشه) یا اصلا اطلاعات توی پایگاه داده نباشه.

در چنین مواردی همونطور که گفتم بهتره pagination توی خود حلقه انجام بشه.

در مورد cache هم کار خارق العاده ای قرار نیست انجام بدین. مثلا کاربر صفحه ۲ را درخواست کرده. وقتی یکبار حلقه را طی کردیم و مقادیر مشخص شده خروجی را توی یک فایل عادی با یک نام منطقی ذخیره میکنیم. مثلا اگه دارین جدول users و صفحه ۲ را cache میکنید میتونید اون را توی www/cache/pagination/users-p2.html ذخیره کنید و دفعات بعد هر وقت کاربر این صفحه را درخواست داد فقط محتویات فایل را بخونیم و براش بفرستیم. توی مرکز کنترل هم هر وقت حذف یا اضافه یا تغییر روی محتوای این صفحه میدیم میتونیم کل فایل هاش را پاک کنیم (با glob راحت میشه با یک دستور این کار را انجام داد) و روز از نو کش از نو ! راه های دیگه هم هست مثلا بر اساس query بیاین cache کنین اما خوب این راهی که گفتم سر راست تره.

اما باز هم میگم اول از همه یک بررسی کامل روی مهندسی پایگاه داده و نرم افزار انجام بدین تا الکی خودتون را درگیر این مباحث نکنید گرچه cache همه جا خوبه اما باید دید آیا واقعا توی performance تاثیری داره !؟ مثلا اگه ۱۰۰۰ تا بازدید در روز بیشتر ندراین نیازی به این کار ها نیست و اصلا به نظر من cache نمیخواد !

حالا تصمیم با شما.
فیلتر کردنمون به این شیوه ست
یک پایگاه داده داریم به عنوان سایت مرجع مثلا که اطلاعات کلیه یوزرها درو اون پایگاه ذخیره میشه
حالا یک سری وب سایت وابسته با پایگاه جدا داریم
خب حالا بعضی از اطلاعات درون اون وب سایت قرار هست برای یک سری کاربر نشون داده بشه و برای یک سری کاربر نشون داده نشه
یا اطلاعات درج شده توسط یک کاربر که درج شده برای فلان کاربر نمایش داده نشه
حالا از اون فراتر هم میره که فلان اطلاعات برای فلان گروه نملیش داده نشه و یا اطلاعات فلان گروه برای فلان کاربر و یا کاربرها نمایش داده بشه یا نشه
خلاصه وب سایتهای وابسته یا زیرمجموعه هرکدوم به نحوی دچار فیلترینگ در داده هاشون هستن
خب اینطوری شامل کلی استثنا میشه که نمیشه همشو توی کوئری گذاشت این رو قبول دارید؟کلی تصمیم منطقی و تصمیم گیرهای منطقی توی این بخش های مختلف هست که همشو نمیشه تو کوئری جا داد
خب اینطوری از یه کلاس استفاده میکنیم که این میاد از داخل حلقه همه استثنائات رو اعمال میکنه
این مشکل فعلا مهم ترین مشکل پیش روم هست
این روش catch کردن رو هم یجوریه از نظرم ایراد داره حالا اون مشکلی نیست راه دارم براش فعلا پس راهی نیست به جز اینکار درسته؟

leaping
یک شنبه 16 فروردین 1394, 11:00 صبح
حتی بهتر هم میشه توضیح داد جناب unique
فرض کنید قراره تو لیست نمایش کاربرها برای فلان مدیر این مدیر محدودیت هایی داشته باشه و یک سری از کاربرها نمایش داده نشن براش
خب در این صورت شما میاید تو کوئری اول از یک دیتابیس دیگه استتخراج میکنید که چه کاربرهایی نمایش داده نشن
خب حالا که این کشف شد باید همه این کاربرهارو مثلا از یک میلیون کاربر 50 هزراتاش قراره نمایش داده نشن براش, خب میاید همه این کاربرها رو درون کوئری به عنوان استثنا قرار میدین و می فرستین واسه دیتابیس؟
حالا در این صورت همچین عملی منطقی هست؟
قطعا در این روش فیلتر باید بهینه ترینش رو انتخاب کرد اما نمیدونم دقیقا چطوری

Unique
یک شنبه 16 فروردین 1394, 17:04 عصر
بگذارین اینطوری بگم :
اگه فیلد های لازم برای تشخیص اینکه اطلاعاتی به کاربر نشون داد بشه یا نه توی یک پایگاه داده باشه اونوقت قطعا بهترین و منطقی ترین راه استفاده از query هست. هیچ نیازی به فیلتر کردن توی حلقه نیست.

از اول هم گفته بودین اطلاعات از یک محل نیست اما واقعا تا دقیق ندونم شما چی را از توی چی میخواین فیلتر کنین نمیتونم نظر بهتری بدم. من منطق برنامه شما را نمیدونم اما مثلا در چنین سناریویی خیلی راحت میشه با query مشکلات فیلتر کردن و اعمال محدودیت ها را حل کرد :

یک سایت جامع مدیریت کتابخونه داریم که هر کتابخونه یک مدیر داره و شامل اعضای کتابخونه هستیم. حالا ما میخوایم محدود کنیم که اعضای کتابخونه یک مدیر فقط به خودش نمایش داده بشه.
خوب قطعا در چنین حالتی کافیه یک کلید خارجی مربوط به کتابخونه توی جدول کاربران داشته باشیم و در زمان خروجی گرفتن توی query بگیم کاربرانی را نشون بده که کتابخونشون با مدیر یکیه !
حالا پیچیده ترش کنیم. مثلا یک جدول امانت کتاب هم داریم. میخوایم مدیر کتاب های امانتی کتابخونه خودش را ببینه و توی جدول امانت هم تعین نکردیم هر امانت مربوط به چه کتابخونه ای هست. کافیه توی جدول امانت ها select بگیریم و روی جدول اعضا یک join بزنیم بر اساس کاربرانی که کتابخونشون با مدیر یکیه !

میخوام بگم توی این موارد عموما مدیر مرتبط با یک چیزی هست که کاربران هم با همون مرتبط هستند و برای فیلتر فقط باید توی where بگیم ارتباطشوت یکی باشه. میخوام بگم اصلا پیچیده نیستش.


خب در این صورت شما میاید تو کوئری اول از یک دیتابیس دیگه استتخراج میکنید که چه کاربرهایی نمایش داده نشن
خب حالا که این کشف شد باید همه این کاربرهارو مثلا از یک میلیون کاربر 50 هزراتاش قراره نمایش داده نشن براش, خب میاید همه این کاربرها رو درون کوئری به عنوان استثنا قرار میدین و می فرستین واسه دیتابیس؟
حالا در این صورت همچین عملی منطقی هست؟
اگه شما اینطوری باید query بگیرین کلا ساختار پیاده سازی پایگاه هاتون غلطه و باید اصلاح بشه. مثال کتابخونه را بخونین تا متوجه بشین منظورم چیه !

leaping
یک شنبه 16 فروردین 1394, 17:52 عصر
میدونم Unique جان چی میگی اما این در صورتی هست که این مثال کتاب خونتون شامل مدیر و زیر رده های مدیریت بشه اما اینجا بحث این هست که هر یوزر برای یک یوزر دیگه میتونه محدود باشه
اصلا بحث این نیست که این کاربرها فقط برای فلان مدیر نشون داده بشن یا نه مثلا وایسید یه pattern بگم
کاربر test1 میتونه واسه یه گروه خاص محدود شده باشه
کاربر test1 میتونه برای یک کاربر خاص محدود شده باشه
کاربر test1 میتونه برای چندین گروه محدود شده باشه
کاربر test1 میتونه برای چندین کاربر محدود شده باشه

همه اینهام میتونن خیلی راحت تغییر داده بشن و قطعا ثابت نیستن

منظور از محدودیت اینکه تمامی اطلاعات و داده های مربوط به کاربر test1 برای اون استثنائات نمایش داده نمیشه و قابلیت ویرایش و حذف هم براش وجود نداره
خب این همه استثنا با ارتباطات جداول حل نمیشه

Unique
یک شنبه 16 فروردین 1394, 19:27 عصر
در چنین حالتی خودم یک function توی mysql میساختم و محدودیت های یک کاربر برای نمایش یا عدم نمایش هر چیزی را توش چک میکردم :

select users_fields ... from table where check_permision(u_id,'users_tbl') = 1 limit m,n

البته حتما performance را توی بازدید مورد انتظارم چک میکردم و قطعا اطلاعات را هم cache میکردم. چون query سنگین در میاد.

leaping
یک شنبه 16 فروردین 1394, 20:29 عصر
در چنین حالتی خودم یک function توی mysql میساختم و محدودیت های یک کاربر برای نمایش یا عدم نمایش هر چیزی را توش چک میکردم :

select users_fields ... from table where check_permision(u_id,'users_tbl') = 1 limit m,n

البته حتما performance را توی بازدید مورد انتظارم چک میکردم و قطعا اطلاعات را هم cache میکردم. چون query سنگین در میاد.
همون دیگه این query خیلی سنگین از آب در میاد.اصلا گیج شدم.
به هر ترتیب ممنون از کمک و راهنماییت