هل يسمح للفئة أن يكون لدي آباء متعددة منطقية؟ هل هناك بدائل؟

Question

سؤال قصير: كيف يجب إدارة فئات المنتج التي تظهر تحت فئات متعددة؟ هل هي ممارسة سيئة للقيام بذلك على الإطلاق؟

معلومات أساسية:لدينا قاعدة بيانات المنتج مع الفئات يحب هذا:

Products

  -Arts and Crafts Supplies
    -Glue
    -Paper Clips
    -Construction Paper


  -Office Supplies
    -Glue
    -Paper Clips

لاحظ أن مقاطع الغراء والورق مخصصة لكلتا الفئتين. وعلى الرغم من أنها تظهر في مكانين مختلفين في شجرة الفئة هذه، لديهم نفس معرف الفئة في قاعدة البيانات. وبعد لماذا ا؟ سببان:

1. يتم تعيين الفئات سمات مخصصة - على سبيل المثال، يمكن أن يكون لديك مقطع ورقي وزن، مادة، لون، إلخ.
2. يتم عرض المنتجات المخصصة للفئة الغراء تحت الفنون والحرف واللوازم المكتبية. والتي من المتوقع - إنها نفس معرف الفئة الفعلية في قاعدة البيانات.

هذا يسمح لنا بإدارة فئة واحدة وسماتها والمنتجات المعينة، ولكن ضعها في أماكن متعددة داخل شجرة الفئة.

نحن نستخدم مجموعة متداخلة نموذج, ، لذلك هيكل DB الذي نستخدمه لدعم هذا هو:

Category
----------
CategoryID
CategoryName


CategoryTree
------------
CategoryTreeID
CategoryID
Lft
Rgt

لذلك هناك 1: م بين الفئة والتصنيف لأن هناك مثيلات متعددة فئة معينة داخل شجرة الفئة.

هل هناك طريقة أبسط للطراز هذا من شأنه أن يسمح فئة منتج للعرض تحت فئات متعددة؟

Answer 1

لا أرى أي شيء خاطئ مع هذا طالما أنه صحيح ذلك الكل الغراء مناسب لكل من اللوازم المكتبية و اللوازم الحرفية.

Answer 2

ما لديك طريقة جيدة، على الرغم من عدم تبسيط الجدول الثاني مثل ذلك:

فئة

اسم الهوية

تصنيف فرعي

معرف الفئة مند الفئات الفرعية

على الرغم من أن المستقبل، سأتحذر من تقاسم فئات الأطفال بين الفئتين الجذرين. في بعض الأحيان يكون من الأفضل إنشاء تصنيف فريد من المنتجات للاتساق، وهو أمر أسهل لإدارة لك ومن المحتمل أن تنقل إلى العميل. خلاف ذلك، لديك مشكلة إذا كنت في صفحة الغراء تأتي من اللوازم المكتبية، ثم تظهر المسار الآخر كذلك؟ إذا لم يكن الأمر كذلك، فلن يكون لديك صفحتان متطابقتان، باستثناء المسار، وهو مشكلة لسيو. إذا قمت بذلك، فقد يتم الخلط بين المستخدم.

Answer 3

المثال الأكثر شهرة لهذا هو بريد جوجل، حيث يتم التصنيف بهذه الطريقة. تشتهر Google في قابلية استخدام منتجاتها ...

أعتقد أن الكلمات الأخرى مفضلة لكلمة "الوالدين"، والتي تشير بالفعل إلى علاقة XTOONE فقط ...

ربما يمكنك أن تقول أن Product كما Categories, ، وبالتالي فإن العلاقة ستكون manytomany. وفقط الشاشة ستبدأ فئات للوصول إلى المنتجات ...

---

هذا من شأنه أن يبرز مشكلة: إذا لم تقصر عدد الفئات، وأنت تعرض الفئات مع الفئات الفرعية وما إلى ذلك، فيمكنك الانتهاء من:

• فئات ضخمة وقائمة المنتجات، مع العديد من الأشكال النسائية
• عمق كبير (ربما غير قابل للقراءة)

الجزء المثير للاهتمام هو تسليط الضوء على المشكلة، ثم تخيل الحل على ما يرام للمستخدم النهائي.

Answer 4

قد يكون ذلك ضروريا للحصول على فئة لديها أولياء أمور متعددة. ومع ذلك، بغض النظر عن الوالد الذي وجدته فئة تحت، يجب أن تظل فئاتها الفرعية هي نفسها.

لقد رأيت أنظمة حقيقية تنفذ هذا المنطق بدقة وعملت بشكل جيد.

تعديل

للإجابة على سؤالك، لا أعتقد أن النموذج الذي أقترحه مقيدا كما تتخيل. في الأساس، يمكن العثور على فرع معين من الشجرة تحت أكثر من فرع أحد الوالدين، ولكن في أي مكان تم العثور عليه، فإنه له نفس الأطفال. لا شيء حول هذا يمنعك من اختيار الكرز بعض الأطفال من فرع واحد وكذلك صنعهم أطفالا آخرين.

لذلك، على سبيل المثال، يمكنك تضمين فئة المواد اللاصقة تحت كل من اللوازم المكتبية ومستلزمات الهوايات، وإذا قمت بإضافة "Crazy Glue (Suppository Edition)" تحت المواد اللاصقة، فسوف تظهر في كليهما. إذا كانت لديك عناصر قد يتم تجميعها بشكل منطقي ولكنك بحاجة إلى فصلها عن طريق استخدامها، فلا يزال بإمكانك القيام بذلك. قد تضع الغوخ والصقها تحت فئة المواد اللاصقة هواية، والتي تنطلق تحت جذر هواية، ولكن ليس تحت جذر المكتب. أو يمكنك القيام بذلك وفي وقت واحد لديك فئة مجتمعة تستخدم داخليا من قبل المشترين الخاص بك. ما لا يمكنك فعله هو أن ينسى تضمين هذا النوع الجديد من الغراء في جميع الفئات ذات الصلة بمجرد إضافتها أينما كنت ينتمي إلى OnTology نموذج أعمالك.

باختصار، تفقد القليل جدا من هذا القيد، ولكن كسب القليل من الهيكل للمساعدة في تجنب مشكلة الاضطرار إلى إدارة كل عنصر بشكل فردي.

تعديل

على افتراض أنني قدمت قضية مقنعة للنموذج نفسه، لا تزال هناك مسألة التنفيذ. هناك الكثير من الخيارات، ولكن هنا طريقة واحدة للذهاب:

يوجد جدول كتالوجيتيم يحتوي على مفتاح أساسي اصطناعي، التسمية، وصف اختياري / تفاصيل نص، و SKU اختياري (أو ما يعادلها). عندئذ يكون لديك الكثير من كتالوجيتيموجوين مع الأطفال والمعرف الأصل، كلا الجانبين مقيدين إلى الكتالوجات القابلة للكتابية.

عنصر يظهر كأحد الوالد هو فئة، لذلك لا ينبغي أن يكون لها SKU. عنصر يظهر فقط كطفل هو منتج، لذلك يجب أن يكون لديه SKU. لا بأس أن يكون لأي عنصر أكثر من أحد الوالدين؛ هذا يعني فقط أنه في فئات متعددة. وبالمثل، لا توجد مشكلة في العديد من الأطفال لكل والد؛ ستكون هذه هي الحالة النموذجية للفئة مع عدد قليل من المنتجات فيها. ومع ذلك، بالنظر إلى معرف الفئة، سيكون أطفالها هو نفسه بغض النظر عن الفئة الأصل التي قادتك هناك. القيد الآخر هو أنك تريد تجنب الحلقات.