سلام وقت بخیر
سال نو پیشاپیش مبارک
من برای جداول لایک ویو و کامنت از رابطه polymorphic استفاده کردم
ولی خوب یه نفر یه مقاله از گیت لب برام ارسال کردن که مطلقا از،polymorphic استفاده نکنم و برای هر مدل جدول جداگانه درسته کنم یعنی اگه به عنوان مثال من سه تا مدل مقالات ویدئو و پادکست داشته باشم هرکدوم باید جدول لایک ویو و نظرات جداگانه داشته باشه
میخواستم نظر شمام بدونم
لینک مقاله 👇👇
رابطه polymorphic
این هم پاسخ ایشون در جواب سوال بنده درباره اینکه چرا نباید از polymorphic استفاده کنم و بهینه بودنش
ببینید مسئول نهایی صحت دادهها، پایگاه دادههاست نه کد. وقتی پلیمورفیک کار میکنید، درسته زحمتتون توی کد کم میشه ولی دیگه دیتابیس هیچ ابزاری مثل Constraint و... نداره که ارتباط رو چک کنه چون ارتباط در لایهی کد و با دو فیلد تعریف میشه. مثلاً ممکنه identifier شما ۵ باشه و table مربوطه پادکست باشه ولی اصلاً پادکست با آیدی ۵ نداشته باشین. همچنین ایندکس و... هم بهینه نیست و سرعت جستجوتون پایین میاد بهینگی همیشه بهمعنای کد و زحمت کمتر نیست
طبق مقاله بالا من نباید کلا از polymorphic استفاده کنم
نظر شما دوستان چیه؟
سلام
من خودم هم قبلا از پلی مورفیک استفاده میکردم ولی توی شرکت های مختلف که کار کردم اکثرا مخالف این هستند و کلا جدول و مدل جدا با آیدی و created و ... میزنن و منم الان چندسالیه همین کار رو میکنم. طبق تجربه بهتر میشه مدیریت کرد روابط رو، خیلی اوقات هم لازمه یکسری فیلد دیگه اضافه کنیم به اون واسط که توی پلی مورفیک امکانش نیست
سلام ممنون از پاسختون
اگر تعداد جداول زیاد بشه
مثلا سه تا کامنت سه تا لایک سه تا ویو
بهینه بنظر میرسه بنظرتون؟
درود
نظر شخصی :
روابط polymorphic سنگین هستن و زمان پردازش هم سرعت رو میارن پایین
برای همین از این نوع روابط برای table شلوغ استفاده نمیکنم
چون شدیدا سرعت میاد پایین
اما برای جداولی که تعداد اطلاعاتشون کمه خیلی مناسبه
تصمیم این قضیه با شماش
هیچ محدودیتی ندارید
مزیت جداول جداگانه اینکه سرعت بالاتری دارید
اگر زیاد بودن تعداد تیبل ها هم براتون اهمیتی نداره چه بهتر
سلام
مقاله جامع و کاملی بود واقعا و نظر دوستان هم خیلی خوب بود
اما در نهایت به نظرم اگر پروژه کوچیک باشه و بدونی مثلا بیشتر از 200 هزار رکورد مثلا حدودی قرار نیست اون جدول پر بشه استفاده از پلیمورفیک خیلی تمیز تر و جمو جور تره
درسته از نظر ایندکسو ارتباط بین جداول ضعف داره اما مثلا برای یه جدولی مثل لایک کردن یا کامنت گزاشتن یا اینچنین مواردی که همه ی فیلد هاش یکسان هست این که بخاییم هی جدول درست کنیم الکی خودمون شلوغ میکنیم
باز هم میگم اگر میدونیم که داده ی خیلی زیادو سنگینی نداریم
چون واقعا اگر اینقد چیز بدی باشه و پرفورمنس رو خیلی داقون کنه فریمورکی مثل لاراول نمیومد و اصلا روابطش رو درست نمیکرد که استفاده کنیمش
پس موارد استفاده داره ولی در جای خودش و به میزان مناسبش
شما با polymorphic مهم ترین اصل پایگاه داده که data consistency هست رو نادیده میگیرید. توی اسکیل کردن هم صددرصد به مشکل میخورید. اگر raw query بنویسید متوجه میشید polymorphic یک موضوع کنترل نشدست در لایه دیتابیس. ( حداقل توی postgres که من کار میکنم به این شکل هست).من به هیچ عنوان و تحت هیچ شرایطی پیشنهادش نمیکنم
با آقای باقری کاملا موافقم
شما از دیتابیس استفاده میکنی که دسترسی سریعتر و منظم تری داشته باشی
استفاده از رابطه polymorphic ، مثل اینکه یه کمد با کشوی بزرگ بسازیم ، بگیم اینجوری یه در هست و ظاهر کمد مینیمال تره
کاربرد کلی دیتابیس رو فراموش نکنید
و اینکه ، لاراول یک فریمورک هست ، هرچقدر هم بهینه و هرچقدر هم سریع ، در نهایت قراره تبدیل به یه کوئری در اون جدول بشه و طبیعتا هر چی اون جدول اطلاعات زیادی تری داشته باشه کار سخت تر میشه
تو ابعاد کوچیک اصلا اهمیتی نداره اما وقتی چندین مدل با روابط مختلف و تعداد بالا داشته باشید متوجه تاثیرات ریز به ریز این جزئیات میشید
آیا مایل به ارسال نوتیفیکیشن و اخبار از طرف راکت هستید ؟