نحوه دسته بندي محصولات در يك Eshop بزرگ

[z_bluestar]

من به تازگي روي يك پروژه eshop كـارمي كنم كه در مورد دسته بندي محصولاتش سردرگم شدم و مي خواستم از شمـا هم در اين مورد نظر بخوام .
اين Eshop مربوط به فروش محصولات صنعت ساختمان مي شه . همون طور كه مي دونيد اين صنعت داراي محصولات بي نهايت و متفاوتي مي باشد و در پايين ترين مقياس داراي 350 گروه كـاملا متفاوت مي باشد .از اونجــا كه اين سايت ، يك سايت تخصصي هست نياز به اين هست براي هر گروه از محصولات ويژگي هاي خاص خودش نگه داري بشه براي نمونه ويژگي هايي كه در زير ليست شده اند براي دو گروه پنجره و شير آب هستند و مي بينيد كه چقدر ويژگي هاي اونها متفاوت هست

http://barnamenevis.org/forum/attachment.php?attachmentid=46551&stc=1&d=1270459679





اگه من بخوام براي هر گروه از محصولات Table مجزايي در dataBase در نظر بگيرم بايد حدود 350 table داشته باشم كه اين غير منطقي مي باشد


به نظر شمـا بهترين روش براي دسته بندي چي مي بــاشد ؟؟؟؟؟؟؟؟؟

[z_bluestar]

البته خودم يه طراحي براي Database كردم ولي اگه بخوام اين سيستم رو داشته باشم انوقت بايد بايد هنگام ويرايش يا اضـافه كردن محصولات فرم ها رو Generate كنم كه اونم واسه خودش كلـي دردسره.

http://barnamenevis.org/forum/attachment.php?attachmentid=46556&stc=1&d=1270462126


به جــاي اينكه بيام براي هر گروه از محصولات يك جدول در نظر بگيرم تمام properties هاي همه گروه هـا رو در يك Table قرار دادم و هنگـام اضافه كردن يك كحصول جديد به يك گروه ميام properties هاي اون گروه رو پيدا كرده و در يك Table براي اون محصول خاص مقدار دهي مي كنم .

آيا چنين چيزي عملي هست و با generate كردن فرم هـا مي تونم انجــامش بدم يا نه ؟؟؟؟

[Alireza_Salehi]

شما این 5 راه (http://stackoverflow.com/questions/695752/product-table-many-kinds-of-product-each-product-has-many-parameters) را دارید:


Single Table Inheritance (http://martinfowler.com/eaaCatalog/singleTableInheritance.html): one table for all Product types, with enough columns to store all attributes of all types. This means a lot of columns, most of which are NULL on any given row. (http://martinfowler.com/eaaCatalog/singleTableInheritance.html)


(http://martinfowler.com/eaaCatalog/singleTableInheritance.html)Class Table Inheritance (http://martinfowler.com/eaaCatalog/classTableInheritance.html): one table for Products, storing attributes common to all product types. Then one table per product type, storing attributes specific to that product type. (http://martinfowler.com/eaaCatalog/singleTableInheritance.html)
(http://martinfowler.com/eaaCatalog/singleTableInheritance.html)Concrete Table Inheritance (http://martinfowler.com/eaaCatalog/concreteTableInheritance.html): no table for common Products attributes. Instead, one table per product type, storing both common product attributes, and product-specific attributes. (http://martinfowler.com/eaaCatalog/singleTableInheritance.html)
(http://martinfowler.com/eaaCatalog/singleTableInheritance.html)Serialized LOB (http://martinfowler.com/eaaCatalog/serializedLOB.html): One table for Products, storing attributes common to all product types. One extra column stores a BLOB of semi-structured data, in XML, YAML, JSON, or some other format. This BLOB allows you to store the attributes specific to each product type. You can use fancy Design Patterns to describe this, such as Facade and Memento. But regardless you have a blob of attributes that can't be easily queried within SQL; you have to fetch the whole blob back to the application and sort it out there. (http://martinfowler.com/eaaCatalog/singleTableInheritance.html)
(http://martinfowler.com/eaaCatalog/singleTableInheritance.html)Entity-Attribute-Value (http://en.wikipedia.org/wiki/Entity-Attribute-Value_model): One table for Products, and one table that pivots attributes to rows, instead of columns. EAV is not a valid design with respect to the relational paradigm, but many people use it anyway. This is the "Properties Pattern" mentioned by another answer. See other questions with the (http://martinfowler.com/eaaCatalog/singleTableInheritance.html)eav tag (http://stackoverflow.com/questions/tagged/eav) on StackOverflow for some of the pitfalls. (http://martinfowler.com/eaaCatalog/singleTableInheritance.html)
(http://martinfowler.com/eaaCatalog/singleTableInheritance.html)


روش پنجم (Entity-Attribute-Value) و روش چهارم (Serialized LOB) دردسر زیادی دارند و در عین حال سرعت پائین مخصوصا روش چهارم کند و پردردسر است. البته روش پنجم بهتر از روش چهارم است.


روش چهارم را به صورت XML شخصا امتحان کرده ام ولی راضی نیستم.


من روش دوم را پیشنهاد میکنم یعنی: Class Table Inheritance
یک جدول برای مشخصات عمومی و به ازای هر نوع محصول یک جدول


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

[z_bluestar]

من روش دوم را پیشنهاد میکنم یعنی: Class Table Inheritance
یک جدول برای مشخصات عمومی و به ازای هر نوع محصول یک جدول



منم اول این روش مد نظرم بود ولی وقتی گستردگی گـروه ها رو دیدم (حدودا 350) گروه یعنی 350 Table برای نگه داشتن مشخصـات اختصاصی هر محصــول به نظرم زیاد منطقی نرسید .:متفکر:

در ضمــن سمت برنامه برای ورود اطلاعات محصولات رو چکــار کنم ؟؟؟ 350 نوع فرم تهیه کنم ؟؟؟؟:افسرده:

[iman_ad]

چرا از serialization استفاده نمی کنی، کاری که .net با profile داره انجام می ده.
به جای هر جدول یک کلاس داری و دیتای serialized شده رو ذخیره می کنی

[raziee]

چرا از serialization استفاده نمی کنی، کاری که .net با profile داره انجام می ده.
به جای هر جدول یک کلاس داری و دیتای serialized شده رو ذخیره می کنی
این مورد فکر نمیکنید سر بار ضافی رو سرور داشته باشه؟

[z_bluestar]

چرا از serialization استفاده نمی کنی، کاری که .net با profile داره انجام می ده.
به جای هر جدول یک کلاس داری و دیتای serialized شده رو ذخیره می کنی

میشه یه کم بیشتر توضیح بدی ؟؟؟؟

من دارم از این سایت الگو می گیرم .
http://www.lowes.com (http://www.lowes.com/)

وقتی توی این سایت روی جزئیات یک محصول کلیک می کنید .
توی این قسمت می تونید توی بخش Specification جزئیات محصول ببینید . و از این جزئیات تو قسمت های مختلف استفاده می شه مثلا در مقایسه محصولات .

به نظــر شمـا این سایت چطوری عمل می کنه ؟؟؟

[salehbagheri]

سورس يه سايتي رو ديدم كه يه همچين موردي رو به شكلي ساده ولي غير تكنيكي انجام داده بود!

به اين صورت كه تمامي مشخصات يك كالا رو به صورت يك رشته قابل جداسازي، در يك ستون از جدول وارد ميكرد!

در هنگام فراخواني كافي بود از يك حلقه ForNext استفاده كنيد و مشخصات رو دونه دونه فراخواني و استفاده كنيد!

[z_bluestar]

خوب توی سایت چه می شه کرد برای ورود اطلاعات اونم توسط خود کـاربران سایت که محصولاتشان را برای فروش بذارن ؟؟؟


به اين صورت كه تمامي مشخصات يك كالا رو به صورت يك رشته قابل جداسازي، در يك ستون از جدول وارد ميكرد!

خوب منم یه چیزی حالا می شه گفت بهتر از این درآوردم ؟؟ (پست دوم )
ولی این دردسرهای generate کردن فـرم ها رو سمت برنامه داره :ناراحت:
برای insert ، Update ، نمایش و استفاده از این اطلاعات برای مقایسه کردن محصولات با هم ؟؟؟

شمــا چیزی نزدیک به 350 گـروه محصول و 500-600 هزار تا محصـول را در نظر بگیرید.

[Alireza_Salehi]

در مورد سریالی کردن:
در پست قبلی هم گفتم بنده عملا روش Serialization رو با متد XML استفاده کرده ام. تمام لایه DataAccess شما مملو از XQuery خواهد شد. به طور عجیبی اعصاب آدم رو میریزه به هم.
در ضمن روش Serialization برای بسیاری کارها که با چند خط Transact SQL قابل انجام است، سربار اضافی تولید می کند و در ضمن حفظ یکپارچگی اطلاعات به سادگی جداول نیست. اگر می خواهید از این روش استفاده کنید از یک روش Serialization مطرح مثل XML یا JSON یا ... استفاده کنید و از روش های من درآوردی استفاده نکنید.
مزیت استفاده از XML قابلیت ادغام XQUERY در SP ها در SQL 2005 است.



اگر جزئیات محصول یک بار تعریف می شود و در آینده تغییر نمی کند من همان تعریف جدول (روش دوم) را پیشنهاد می کنم.
در صورتی که برنامه شما قرار است حاوی بخش تعریف محصول (تعریف یک محصول-حذف، ویرایش و اضافه کردن جزئیات چه قبل و چه بعد از اضافه کردن محصول) در این صورت روش آخر بهتر است یعنی pivot کردن.
البته این روش Pivot کردن یک سری جاها سربار شدیدی رو سیستم میذاره و در گزارش گیری هم مشکلاتی ایجاد میکنه. (با کمی وقت بیشتر و بهینه سازی بیشتر نتیجه مطلوب حاصل میشه)
ولی برای حالتی مثل این که Attribute ها دینامیک هستند و تغییر می کنند به نظرم خیلی بهتر از سریالی کردن هست. هر چند در مواردی نسبت به روش جدولی سربار دارد.

چند وقت پیش یک SP داشتیم که روی یک سیستم Entity-Attribute-Value (http://en.wikipedia.org/wiki/Entity-Attribute-Value_model) (روش پنجم) قرار بود گزارش تهیه کنه تعداد این SP به روش معمول نوشته شده بود برای یک درخواست 10 دقیقه وقت صرف میکرد، دو روز وقت گذاشتیم 100 جور کلک زدیم رسوندیمش به 2 ثانیه. ولی اگر سیستم جدولی بود (روش دوم) از همون اول همون 5 ثانیه میشد.

[z_bluestar]

همون روش که خودم در نظر داشتم تست کردم و جواب داد و فکــر کنم سر بار کمتری نسبت به بقیه روش ها داشته باشه.
بعد از تکمیل شدن کد نویسش تو تالار ASP میذارم تا بقیه هم بتونن استفاده کنن

[m.hamidreza]

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

[z_bluestar]

توصیه سازنده::لبخندساده:
در این پروژه برای طراحی دیتابیس اصلا عجله نکنید!

ممنون از راهنمـايي تون ، من عجلــه اي ندارم ولي صاحب سايت حســابي عجلـه داره .:عصبانی++:

منم فعلا يه Database نمونه درست كردن و تو سايت با اون كد نويسي هايي كه تو ذهنم هست دارم تستش مي كنم كه آيا جواب مي ده يا نه ؟؟؟

فعلا بعد نبوده و داره جواب مي ده .
بعد از تكميل سعي مي كنم اينجـا مطرحش كنم.

[pourang_us]

دوست عزیز

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


موفق باشید

[z_bluestar]

مسئله اینه که این یه سایت که برای کــانادا داره تهیه می شه .اطلاعات در مورد محصولات ، گروه محصولات و اطلاعات هر گروه جمع آوری شده والگوهــای درون اینترنت هم بررسی شده اند .
مشکل اینه که این اطلاعات چه شکلی دسته بندی بشن که هم کـار کد نویسی رو کم کنند و بهترین راه حل هم از نظر سر باری سیستم باشه .

حــالا نمی دونم منظور شمــا از عجله چیه ؟؟؟؟

همون که گفتم در حال تست کردن روش خودم هستم که ببینم برای این حجم اطلاعات جوابگو هست یا نه ؟؟؟؟

[hinatiloos]

ببینی یه راه حل بسیار یاده داره
مهم نیست چند تا خاصیت داری من میگم شما بینهایت خاصیت و ویژگی دارید برای هر محصول داری و هر محصول ممکنه 1-2-10-100-500 و یا بینهایت خاصیت داشته باشه.
شما 2تا تیبل نیاز داری:
تیبل1-
در این تیبل یک آی دی میزاری و یک Typeآی دی رو اوتو میکنید و در تایپ خاصیت های همه محصولات رو مینویسد.
مثلا:
ID=1 Type:رنگ محصول
ID=2 Type:طول


تیبل2:
در این جدول فیلد های زیر رو داری:
1-Id
2-IDتبل 1
3-Type
4-Id محصول



بدین ترتیب در جدول 2 که داررای آی دی محصول هست به محصول اشاره می کنی و به ازای هر ویژگی یک رکورد درج می کنید.به این ترتیب اصلا مهم نیست که سما چند ویژگی داشته باشید و یا اینکه تعدا ویژگی های محصولات کم و زیاد باشه.