PDA

View Full Version : پاسخ نظری به یک سناریو در ارتباط با php و mysql



leaping
سه شنبه 18 اسفند 1394, 04:49 صبح
سلام دوستان
میخواستم بدونم در ارتباط جداول زیر با دیتابیس mysql چه سناریو پیاده سازی کنم بهتره؟

ببینید برای یک وب سایت نمایش ویدئو ما چندتا جدول داریم با عناوین زیر
videos = جایی که الاعات کلی فیلم ذخیره شده
cast = جایی که عوامل فیلم ذخیره شده
pictures = جایی که نام و مسیرهای مربوط بخ تصاویر فیلم ذخیره شده
videomedia = جایی که ویدئوهای مربوط فیلم ذخیره شده (داده های مربوط به اون)
viewer = جایی که داده های مربوط به بازدید کنندگان فیلم ذخیره شده
genre = جایی که ژانرهای مربوط به فیلم ذخیره شده

خب حالا برای صفحه اول وب سایت ما میخوایم چندین تا ویدئو رو به مشخصات مربوط به خودش نمایش بدیم

حالا برای این کار از subquery ها استفاده کنم و یا از join و inner join

اگه از join و inner join استفاده کنم قضیه به چه ترتیب پیش میره؟

میشه یه query سنگین که قراره چندین نوع داده رو باهم مقایسه کنه در کل منظورم این هست که میدونم همواره join سرعتش از subquery بیشتره اما خب تو این سناریو یکم query پیچیده میشه چون هر کدوم از داده های دارای محدودیتهایی هستن و از اون سمت هم به هر رتتیب mysql توسط cpu باید این داده هارو پردازش کنه اگر سرعت بیشتر در هنگام کانکت زدن های مجدد هست
ممنون میشم query مورد نظرتونو برام بنویسید ببینم شما چی به ذهنتون رسیده

sadegh1362
سه شنبه 18 اسفند 1394, 07:07 صبح
سلام
شما اگرمیخواید query های بهینه داشته باشید . و دردسرهای اینطور چیزا رو برای همیشه حل کنید .بهتره از library های دیتابیس mysql استفاده کنید . چون اونا خودشون میتونن بررسی کنن دیتابیس رو query بهینه تولید کنن.
یه مزیت دیگه هم دارن اونم اینه که محیط شی گرایی در دیتابیس به شما میدن به جای query و شما وقتت رو توی نوشتنquery تلف نمیکنی. فریم ورکهای معتبر php هم الان دارن از همین library ها استفاده میکنن. که به اصطلاح بهشون میگن ORM یا .Object relational mapper
من به طور مثال doctrine رو مثال میزنم . لینک سایتش (http://www.doctrine-project.org/)

leaping
سه شنبه 18 اسفند 1394, 08:51 صبح
دوست عزیز من دارم از فریمورک phalcon استفاده میکنم که این امکانات رو خودش داره
منظور بنده رو بد متوجه شدین.
واکشی داده ها به چند صورت میتونه امکان پذیر باشه

ممنون میشم اگر دوستان به اصل جواب پاسخ بدن اول, تا بعدا به چیزهای دیگه هم در همین رابطه برسیم :لبخندساده:

sadegh1362
سه شنبه 18 اسفند 1394, 09:55 صبح
دوست عزیز من دارم از فریمورک phalcon استفاده میکنم که این امکانات رو خودش داره
منظور بنده رو بد متوجه شدین.
واکشی داده ها به چند صورت میتونه امکان پذیر باشه

ممنون میشم اگر دوستان به اصل جواب پاسخ بدن اول, تا بعدا به چیزهای دیگه هم در همین رابطه برسیم :لبخندساده:

:لبخندساده:
یه کوئری توسط orm ی که phalcon داره با inner join , join بگیرید . بعد تو objectش نگاه کنید . سعی کنید query هاش رو string کنید ببینید . منظورم رو متوجه میشید .

خودش بهینه میکنه .
من هم با yii کار میکنم .
موفق باشید .

مهرداد سیف زاده
سه شنبه 18 اسفند 1394, 10:29 صبح
در مورد صفحه اول در پروژه ای مثل پروژه شما مجبور بودم صرفا برای نشون دادن ۱۰ مورد چنان کوئری سنگیتی بزنم
برای همین بعد از اضافه شدن هر مقدار به دیتابیس تیبلی داشتم برای صفحه اول که میرفتم اون رو update میکردم. همچنین بیشترین نظرات و بیشترین بازدید هم چنین چیزی بود. البته برای نظرات و بازدید cron هر ۵ دقیقه گذاشته بودم.
ولی این همیشه کابرد نداره. چون بعضی چیزها باید live گرفته شده و شاید نتونید برای رسیدن به performance بالاتر از join پرهیز کنید
ولی نوع داده و همچنین تعداد relation های بین table ها روی join خیلی تاثیر داره
subquery همیشه باعث بالا بردن سرعت نمیشه. در زمانی subquery خوب هست که شما مثلا یه دسته بندی ۱۰ تایی دارید و بعد در تیبل دیگری برای هر کدوم از این دسته‌ها ۵۰۰ تا ردیف دارید. این جا یک بار بر روی table اول query میزنید و بعد روی تیبل دوم. ولی اگر دو تا تیبل هر کدوم داده‌ها و ردیفهای سنگینی دارن اون وقت دیگه subquery هم چندان کاربرد نداره
توصیه میکنم در حد لزوم برای performance وسواس داشته باشید. و شاید بعضی جاها صرفا برای بالابردن یه performance کوچیک، باگهای بزرگی رو برخورد کنید.

Unique
سه شنبه 18 اسفند 1394, 17:52 عصر
join انقدر ها هم که میگین وحشتناک و اسمش را نبر نیست. scale شما چه داره ها و چه تعداد بازذیدکنندگان و چه سخت افزار و منابعتون خیلی اهمت داره. join اگه با رعایت نوع داده مناسب و relation های درست و index صحیح باشه و در جاهایی از cache کردن به درستی استفاده بشه و سخت افزار و منابع متناسب با بازدید سایت وجود داشته باشه قابل اطمینانه. کلا تا سایت را طراحی نکنید و زیر بار نبرید متوجه نمیشین باید چیکار کنین. تصمیم گیری های تئوری قابل استناد نیستند.