حمیدرضا سلیمیان

بلاگ شخصی حمیدرضا سلیمیان

دسته بندی مقالات
باهم در شبکه های اجتماعی !

برسی یک مشکل در طراحی دیتابیس،چند محصول با ویژگی های متغییر؟

برسی یک مشکل در طراحی دیتابیس،چند محصول با ویژگی های متغییر؟

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

  • ایجاد،مشاهده،آپدیت،حذف یک محصول
  • ایجاد یک ویژگی جدید برای یک نوع محصول
  • جستجو بر اساس ویژگی های یک نوع محصول

را نیز احتیاج دارید . خوب برای طراحی این ساختار در دیتابیس که ویژگی های بالا رو برطرف کنه شما چندین روش برای حل این موضو ع دارید

 

ایجاد جدول برای هر محصول

خوبی ها : خوب این روش واضحه این که شما باید برای هر محصول یک جدول ایجاد کنید و مشخصا ویژگی های عمومی و خاص اون محصول هر کدام یک فیلداون جدول رو تشکیل میدن . شما به راحتی می تونید با دستورات sql محصولی را ایجاد ویرایش و حذف و جزعیات اون رو مشاهده کنید . و چون ویژگی ها هر کدام یک فیلد است جستجوی آن نیز بر اساس ویژگی ها به راحتی قابل انجام استr و با یک ایندکس بندی مناسب روی فیلد ها می تونید سرعت خیلی خوبی هم برای جستجو بدست بیاریدr
مشکلات : برای ایجاد یک ویژگی جدید به محصول باید ساختار جدول تغغیر پیدا کنه و همینطور برای ایجاد یک محصول باید یک جدول جدید ایجاد بشه که اینکار باید توسط خود برنامه نویس و طراح اضافه بشه یا اینکه توسط کاربر و توسط یک برنامه واسط انجام بشه که خودش مشکلاتی رو از قبیل تکراری بودن فیلد ها . انتخاب اشتباه نوع فیلد امکان ایندکس گزاری و اینکه درست ایندکس نتونه بکنه و... که در کل همه این ها ناشی از اونه که ساختار نباید توسط شخصی متخصصی غیز از طراح و یک برنامه نویس انجام بشه .

جدول مشترک با فیلد های پیش فرض برای ویژگی ها

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

خوبی ها : ایجاد مشاهده آپدیت و حذف محصول به آسانی امکان پذیر است و جستجو در آن با ایندکس بر روی فیلد نوع محصول ،بسیار راحت و سریع است و چون همه محصولات در یک جدول است کاربر نیز می تواند محصول ایجاد کند بدون ان که در ساختار جدول دستکاری شده باشد

مشکلات : محدودیت در تعداد فیلد ها. برای مثال در مثال بالا ما سه فیلد پیش فرض برای ویژگی ها انتخاب کردیم بنابراین برای هر محصول حدهاکثر 3 ویژگی می توان تعریف کرد و از طرفی دیگر برای رفع این محدودیت با افزایش تعداد فیلد های پیش فرض باعث افزایش رکوردهایی با خانه های خالی زیاد پیدا می کنیم. برای مثال اگر محصول مانیتور های ما دارای 20 ویژگی باشند و محصول لباس ما همان 2 ویژگی ما مجبور به ایجاد 20 فیلد پیش فرش برای جدول می شویم که این کار باعت می شود 18 فیلد از رکوردهای محصول لباس همیشه خالی باشد.
از دیگر مشکلات این طرح اینست که ما باید از ساختاری استفاده کنیم که در آن مشخص باشد فیلد پیش فرض اولی مربوط به چه ویژگی از ان محصول است برای مثال این ساختار تعیین کند که فیلد پیش فرض اول برای محصولات مانیتور سایز است و برای محصولات لباس رنگ است . این ساختار می تواند در یک جدول دیگر و یا حتی در کد تعیین شود که هر دو روش استانداردی نیست و در کل توسعه سیستم را سخت می کند.

جدول مشترک با یک فیلد پیش فرض برای همه ویژگی ها

در این طراحی یم فیلد با طول زیاد برای جدول در نظر میگیریم و تمام ویژگی ها را با فرمتی مانند json در قالب یک رشته در آن فیلد ذخیره می کنیم

خوبی ها : ایجاد و حذف یک محصول آسان است چون تمامی ویژگی ها در یک فیلد ذخیره شدند مشکل و محدودیتی جدی برای ایجاد یک ویژگی برای نوعی محصول نداریم.و همچنین برای ایجاد محصول جدیدr چون اطلاعات در فیلد ویژگی ها از نوع json بوده و به صورت key/value ذخیره می شود ، مشکل قبلی برای تعیین ساختار جداگانه برای تعیین جایگاه فیلد مورد نظر نداریم. نسبت به طرح قبلی استاندارد و قابل توسعه بیشتری است

مشکلات : سرعت جستجوی آن نسبت به موارد قبلی کمتر است . چون در این حالت باید رشته مورد نظر پردازش شود برای این کار از یکسری توابع خود mysql باید استفاده بشود که در حالت پیش فرض فعال نیست . برای نصب و راه اندازی این تابع از این لینک استفاده کنید

طرح EAV

entity attribute values , یک مدل استاندارد برای مدیریت ویژگی های محصول . در این مدل ویژگی های خاص هر محصول در یک جدول جدا گانه و همچنین آن مقدار آن ویژگی ها نیز در یک جدول دیگر ذخیره می شود

در طرح بالا

  • دو نوع محصول داریم : لباس و مانیتور ! (product_type)
  • این دو نوع محصول ویژگی هایی دارند : لباس دارای دو ویژگی سایز و رنگ ، مانیتور دارای دو ویژگی سایز و رزولوشن(product_fields)
  • چهار محصول اضافه شده : دو لباس و دو مانیتور (product)
  • لباس c1 ویزگی رنگ آن blue و ویژگی سایز آن large تعریف شده ، برای لباس c2 فقط ویژگی رنگ با مقدار red تعریف شده (product_values)
  • برای مانیتورmon1 ویزگی سایز و رزولوشن مقدار دهی شده ولی برای مانیتور mon2 فقط ویژگی سایز مقدار دهی شده (product_values)

 

 

خوبی ها : یک مدل رایج در سیستم ها توسعه پذیر که بخاطر جدا بودن ویژگی ها در یک جدول دیگر ،امکان ایجاد محصول و ایجاد یک ویژگی خاصبرای یک محصول در آن ساده تر است و در واقع هیچ گونه محدودیتی برای ایجاد وجود ندارد

مشکلات : جستجو بر اساس ویژگی های خاص یک محصول دستور پیچیده و تاحد زیادی روی دیتا بزرگ کند است .چون نوع همه مقادیر ویژگی ها از یک نوع است باید بررسی نوع(validation) وارد دشده توسط کد انجام گیرد


شما با توجه به نوع پروژتون و بزرگی و کوچک بودن دیتا می تونید یکی از 4 روش بالا را انتخاب کنید.

درسته که روش EAV استاندارد ترین روش است و فروشگاه ساز های بزرگی مثل Magento ازش استفاده می کنن ، ولی باید توجه داشته باشید که کند ترین روش هم محسوب میشه.

در مقاله بعدی سعی می کنم بیشتر به این مدل بپردازم و حتی query های جستجو حذف و ایجاد ویژگی رو توضیح بدم


منابع برای توضیح بیشتر

نام
ایمیل
متن نظر
عبارت داخل تصویر
 
سحر
۱۳۹۳/۱۲/۲۲ ۱۰:۲۰
مقاله خوبی بود. من دارم یه فروشگاه بوتیک درست می کنم که قراره بعدا صفحات جداگانه ای به فروشگاه های دیگه اختصاص بدم یعنی چندتا فروشگاه خواهم داشت از آنجا که محصولات کیف و کفش و لباس و جواهرات زینتی هستند فکر می کنم بخاطر سرعت و حجم بالای اطلاعات و خصوصیات متفاوت از روش دوم استفاده کنم نظر شما چیه؟
▬▬حمیدرضا سلیمیان
۱۳۹۴/۰۳/۱۹ ۰۰:۰۰
اگر فروشگاهایی که میخاید اختصاص بدید محصولات مشخصی دارند و نخاند محصول جدید و دلخواهی درست کنند پیشنهاد من روش اول و دوم و اگر محصولات اونها بیشترش مشترک وو تعدادی فیلد متفاوت با بقیه فروشگاها دارند گزینه 3 و اگر هر فروشگاه محصولات کاملا متفاوت دارند قطعا بهترین گزینه استفاده از روش چهارمه 
afshin
۱۳۹۴/۱۰/۱۴ ۱۸:۵۴
حمید خان واقعا دست خوش .. کارت عالیه
rezakia
۱۳۹۵/۰۴/۳۰ ۱۴:۰۹
سلام ممنون بابت مطلب مفیدتون،خیلی کاربردی و بدرد بخور بود
ابوالفضل
۱۳۹۵/۰۸/۰۷ ۱۱:۳۰
بسیارعالی مخصوصا روش eav رو تا حالا کارنکرده بودم