نحوه ذخیره فیلدها در چند نوع محتوا در دیتابیس

4 هفته پیش توسط websaz آپدیت شد
آفلاین
user-avatar
websaz ( 32090 تجربه )
4 هفته پیش
تخصص : برنامه‌نویس وب: Php :: Drupal :: Laravel

لینک کوتاه اشتراک گذاری

0

سلام
در یک سایت اطلاع رسانی چند نوع محتوا داریم.
news
article
book
که قطعا یکسری فیلد مشترک و یکسری فیلد اختصاصی دارند.
می خواستم از دوستانی که تجربه بیشتری در ساخت laravel database schema دارند کمک بگیرم برای چینش صحیح دیتابیس در سایت های خبری .
بهتر هست هرنوع محتوا فیلدهای اختصاصی خودشون را داشته باشند مثلا فیلدها در اخبار و مقالات و کتابها تکرار بشه یا اینکه بصورت روابط polymorphic ذخیره بشه.
اگر دوستان مطلب یا محتوایی راهنما هم داشته باشند ممنون می شم معرفی کنند.

بهترین پاسخ
آفلاین
user-avatar
محمدحسن یگانه
4 هفته پیش

به نظرم این قضیه یک Trade-Off محسوب میشه و باید بسته به شرایط و نیازتون سبک سنگین کنید.

مزیت اینکه اطلاعات هر کدوم بصورت مجزا در جدول خودشون ذخیره بشه ساده شدن کار و سرعت دسترسی بالاتر به اطلاعات در مواقع مختلف هست. و مزیت اینکه بصورت روابط PolyMorphic پیاده سازی بشه شاید این باشه که جدول اصلی ساده تر و سبک تر باقی می‌مونه و سرعت کوئری گرفتن بالاتر میره.

با ذکر این دلایل و بصورت کلی پیشنهاد من اینه:

فیلدهایی که جزو اطلاعات اصلی و پرکاربرد یک Entity هستند مثل title و publishdate و status و thumbnail و ... با اینکه احتمالا در سایر موارد هم تکرار می‌شوند، بهتر هست که به صورت مجزا و هر یک در جدول خودشون قرار بگیرند. چون خیلی سخت و عجیب خواهد بود اگر هر سری برای گرفتن عنوان یک کتاب یا مقاله از Relation ها اون هم PolyMorphic استفاده کنید. وقتی خیلی تمیزتر و ساده تر می‌تونید مثلا از book->title$ استفاده کنید.

اما یکسری موارد دیگه مثل برچسب های موضوعی، کامنت، تصاویر پشتیبان و ... خیلی موارد مناسبی هستند که بصورت PolyMorphic و مشترک بین همه شون طراحی شوند. چون اولا اکثرشون به این موارد احتیاج دارند و مشترک هست. و دوما موارد استفاده شون نسبت به حالت قبل کمتر هست و بصورت کلی می ارزه. به همین خاطر منطقی نیست برای هر یک از Entity های book و‌ article و news یک جدول جداگانه برای ذخیره برچسب ها یا کامنت هاشون داشته باشیم. وقتی همه چیزشون مثل هم و مشترکه.

آفلاین
user-avatar
محمدحسن یگانه ( 96059 تجربه )
4 هفته پیش
تخصص : Full-Stack Web Developer Freelancer

لینک کوتاه اشتراک گذاری

0

به نظرم این قضیه یک Trade-Off محسوب میشه و باید بسته به شرایط و نیازتون سبک سنگین کنید.

مزیت اینکه اطلاعات هر کدوم بصورت مجزا در جدول خودشون ذخیره بشه ساده شدن کار و سرعت دسترسی بالاتر به اطلاعات در مواقع مختلف هست. و مزیت اینکه بصورت روابط PolyMorphic پیاده سازی بشه شاید این باشه که جدول اصلی ساده تر و سبک تر باقی می‌مونه و سرعت کوئری گرفتن بالاتر میره.

با ذکر این دلایل و بصورت کلی پیشنهاد من اینه:

فیلدهایی که جزو اطلاعات اصلی و پرکاربرد یک Entity هستند مثل title و publishdate و status و thumbnail و ... با اینکه احتمالا در سایر موارد هم تکرار می‌شوند، بهتر هست که به صورت مجزا و هر یک در جدول خودشون قرار بگیرند. چون خیلی سخت و عجیب خواهد بود اگر هر سری برای گرفتن عنوان یک کتاب یا مقاله از Relation ها اون هم PolyMorphic استفاده کنید. وقتی خیلی تمیزتر و ساده تر می‌تونید مثلا از book->title$ استفاده کنید.

اما یکسری موارد دیگه مثل برچسب های موضوعی، کامنت، تصاویر پشتیبان و ... خیلی موارد مناسبی هستند که بصورت PolyMorphic و مشترک بین همه شون طراحی شوند. چون اولا اکثرشون به این موارد احتیاج دارند و مشترک هست. و دوما موارد استفاده شون نسبت به حالت قبل کمتر هست و بصورت کلی می ارزه. به همین خاطر منطقی نیست برای هر یک از Entity های book و‌ article و news یک جدول جداگانه برای ذخیره برچسب ها یا کامنت هاشون داشته باشیم. وقتی همه چیزشون مثل هم و مشترکه.

آفلاین
user-avatar
websaz ( 32090 تجربه )
4 هفته پیش
تخصص : برنامه‌نویس وب: Php :: Drupal :: Laravel

لینک کوتاه اشتراک گذاری

0

سلام
ممنون بابت وقتی که گذاشتید و پاسخ کاملتون.
من خودم هم مورد نظرم همین روش بود. البته در drupal و wordpress روش ذخیره در دیتابیس فرق می کنه و فیلدها مستقل ذخیره می شن که اون هم بدلیل اینکه کاربرها فیلدها رو خودشون درست می کنند هست و روش دیگه ای نداره.
ممنون بابت کلید واژه Trade-Off .سرچ کردم و کلی مطلب مفید پیدا کردم.
دوستان دیگه هم اگه تجربه ای دارند بفرمایند ممنون می شم.

برای ارسال پاسخ لازم است، ابتدا وارد سایت شوید.