قرار دادن یک محصول در چند دسته

[freddy]

سلام
اگر محصولی را در عضو چند دسته بخواهیم ایجاد کنیم باید چکار کرد
مثال :
نرم افزار email که اطلاعات خواص خود را دارد در دسته بندی ها، در دسته های 1مانند . اینترنت/2. ایمیل/3. ....4....5...
قرار می گیرد که هر کدام از این دسته ها به سری نرم افزارهای خود اشاره دارد .
حالا اگر این نرم افزار را بخواهیم در چند category قرار دهیم که در هنگام نمایش دسته های قرار گیری نیز ذکر شده است باید چکار کرد .
ایا این تغییرات در sql انجام می شود یا در سطح برنامه نویسی لایه وب .
ممنون از توجه شما دوست گرامی .

[حمیدرضاصادقیان]

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

[freddy]

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

[حمیدرضاصادقیان]

سلام.در واقع جدول TAG هم همون کار جدول میانی رو انجام میده.چون شما باید ترکیب دو فیلد کد گروه کالا و کد کالا و کلید بگیرید که یک کالا بتونه توی گروههای مختلف باشه.

[m_omrani]

البته قضيه هميشه به اين سادگي ها هم نيست.

به عنوان مثال همين تالار گفتگوي برنامه نويس رو در نظر بگيريد. فرض کنيد مطلبي تحت عنوان مشکل يک برنامه C# در پايگاه داده SQL Server مطرح بشه. فرد پرسش کننده نمي دونه بالاخره بايد اونو در قسمت C# مطرح کنه يا SQL Server. چون مطلب مورد بحث تحت هر دو قسمت قرار مي گيره. هيچ الزامي هم نمي تونيم تعيين کنيم که مطلب بايد در SQL Server يا C# باشه.

اين مساله چيزي مثل وراثت چندگانه رو به ذهن مياره که يک فرزند داراي چند والد مي تونه باشه. اما به عقيده من اين رو نبايد اين طوري نگاه کرد. چون در اين حالت ديگه يه درختواره نداريم که به طور ساده بخواهيم مطالب رو زير شاخه هاي مختلف قرار بديم. بلکه با يک گراف طرف هستيم و در يک گراف هم چيزي تحت عنوان گره والد معني نمي ده که بگيم فلان گره فرزند فلان گره هست (مگر اين که گراف جهت دار باشه و فرزند بودن رو قراردادي تعريف کنيم)، بلکه ارتباط بين گره ها مطرحه (مثلاً يک گره با تعدادي گره ديگه ارتباط داره)، ضمن اين که جهت پيمايش هم در اينجا اهميت پيدا مي کنه.

اين که از يک گره چه مسيري به سمت گره بعدي بريم. در اين حالت پرس و جو ها بسيار بسيار مي تونه پيچيده بشه، چون به راحتي مي تونيم به Loop بيفتيم.

در مثال قبل ممکنه بگيد خوب با چيزي شبيه تگ زدن، کلمات کليدي و نظاير اون براي موضوعي که قراره در تالار گفتگو درج بشه ارتباط اون رو با مباحث مختلف نشون مي ديم.

اين دقيقاً نکته ظريف مساله است. چون در واقع فرار از اصل مساله است. بله. تعريف کلمات کليدي و تگ ظاهراً چيز خوبيه. اما به شرطي که به صورت معني دار تعريف بشه، نه به صورت يک باکس متني که کاربر دستي کلمات کليدي رو توش تايپ کنه (يعني هر تگ يا کلمه کليدي بايد دقيقاً به صورت يک رکورد تعريف شده باشه و براي يک Topic يک جدول جدا شبيه Topic_Keywords بگيريم). اما حتي با اين پياده سازي هم مساله به طور کامل حل نميشه، چون تمامي کلمات کليدي به صورت خطي با هم ارتباط دارن و همگي در يک سطح هستند. راه درست اينه که خود کلمات کليدي رو هم دسته بندي کنيم.

و اين همون نقطه ايه که مي خواستم برسيم. در اين حالت شما هر کلمه رو زير چه دسته اي قرار مي ديد؟

به عنوان مثال کلمه «باگ» رو مي خوايد زير شاخه «SQL» قرار بديد يا «C#»؟ مساله هم همين جا است! اصلاً مدل درختواره در اين حالت صحيح نيست. معني نمي ده که حتماً يک کلمه زير دقيقاً يک دسته قرار داشته باشه و از اون نشات بگيره.

در چنين حالتي به عقيده من طراحي ديتابيس اساساً فرق مي کنه و بايد با ديد ديگه اي طراحي بشه.

به عنوان مثال ساختار زير رو ببينين:



Entity Entity_Entity
+----------+ +-------------------+
| EID (PK) | | EEID (PK) |
+----------+ ---------E +-------------------+
| Title | | EID (FK) |
+----------+ +-------------------+
| RelatedEID (FK) |
+-------------------+
در اينجا يک Entity مي تونه تعدادي Entity مرتبط داشته باشه که خودشون Entity هستن.

اين به سناريوي قبل جواب مي ده. به زير توجه کنين:


Entity Entity_Entity
+-------------+ +------+-----+------------+
| EID | Title | | EEID | EID | RelatedEID |
+-------------+ ---------E +------+-----+------------+
| 1 | Bug | | 100 | 1 | 2 |
+-------------+ +------+-----+------------+
| 2 | C# | | 101 | 1 | 3 |
+-----+-------+ +------+-----+------------+
| 3 | SQL | .
+-----+-------+ .


و در اينجا براي تگ زدن مطلب ما از EID استفاده نمي کنيم، بلکه از EEID يعني کليد جدول Entity_Entity استفاده مي کنيم. در اين حالت براي EEID = 100 دقيقاً مي دونيم مقصود باگ مربوط به C# هست و با EEID = 101 معلوم مي شه مقصود باگ مربوط به SQL هست.

بابت طولاني شدن صحبت از دوستان عذرخواهي مي کنم.

منتظر شنيدن نظرات دوستان هستم.

[freddy]

ممنون از توضیحات m_omrani
البته در اکثر وب هایی که دیدم این موضوع رو با tag پوشش دادن
در واقع در بخش tag از category های موجود خود استفاده کردن .
به هر حال داشتن 2 جدول نیاز هر دو طرف رو براورده می کنه .
1. برای Keywords .
2. برای Categorys .


ممنون .