قيود نموذج ExternalKey في جانغو

Question

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

الآن، أنا أتحكم في هذا من وجهة النظر:

parent_candidates = list(Category.objects.all())
pruned_parent_list = [cat for cat in parent_candidates if instance.id not in cat.getHierarchy()]

حيث المثيل هو الفئة التي يتم تحريرها وgetHierarchy() هي طريقة للحصول على قائمة بمعرفات الأسلاف.

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

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

Answer 1

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

• إنترنت
  • جوجل
  • ياهو
• غير متصل على الانترنت
  • مايكروسوفت أوفيس
  • مكتب مفتوح

الطريقة التي أتعامل بها عادةً هي أنه من الواضح أن لدي Parent_id FK في جدول الفئات.بالنسبة للعناصر الجذرية (الإنترنت، دون الاتصال بالإنترنت)، سيكون المعرّفparent_id هو 0.لذلك، عندما تحاول في العرض الخاص بك استرداد "الفئات الأصلية" للقائمة المنسدلة، يتعين عليك أن تقرر إلى أي مدى يمكن أن تستمر في التداخل.أقتصر هذا في الغالب على المستوى الأول، لذا لاختيار الفئات التي تريد إظهارها في القائمة المنسدلة، عليك أن تفعل شيئًا مثل:

parents = Category.objects.filter(parent_id=0)

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

على أية حال، آسف على الرد الطويل، وآمل أن يكون هذا قد حل مشكلتك إلى حد ما.

Answer 2

لقد كان

وأنا على التعامل مع فئات التعسفي متعمقة على SQL وعلى ما يبدو ليس مناسبة تماما لتخزين البيانات من هذا النوع في شكل طبيعي، كما الاستفسارات متداخلة و / أو متعددة ينضم تميل إلى الحصول على القبيح <م> للغاية بسرعة.

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

وجدول الفئات أن ننظر بشيء من هذا القبيل:

id    name
1     Internet
2     Internet/Google
3     Internet/Yahoo
4     Offline
5     Offline/MS Office/MS Excel
6     Offline/Openoffice

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

وعلى أية حال، البيانات الهرمية في SQL ليست تافهة في حد ذاته، لذلك، مهما فعلت، وربما لديك لتفعل بعض الترميز المخصصة.

Answer 3

ونلقي نظرة على التطبيق جانغو-treebeard.

Answer 4

و"هل هناك أي طريقة أفضل للقيام بذلك؟" ليس صحيحا. التسلسلات الهرمية من الصعب في نموذج العلائقي. لا شيء يجعل من الأسهل إلا التخلي عن SQL تماما.

و"كتابة آلية الاختيار في القالب الخاص بي بواسطة حلقات من خلال pruned_parent_list للحصول على خيارات" - ربما لا المثلى. يجب أن يحدث هذا في وجهة نظركم.

Answer 5

وأنا لست متأكدا إذا كان هذا هو أفضل (التفاعل الحكمة أو غير ذلك) ولكن ...

ويمكنك التحقق من سلامة الهرمية على حفظ ورفع خطأ إذا لزم الأمر.

ومثاليا لمثل هذا النوع بيانات أود أن نرى شجرة من الحالات على الجانب. أو على الأقل الجدودية كاملة عن وجهة نظر الكائن التفاصيل. في كلتا الحالتين كنت بالفعل قد فعلت رحلة إضافية المذكورة إلى قاعدة البيانات.