Modèle d'objet:
class Category(models.Model): title = models.CharField(max_length=50) def __str__(self): return f"{self.title}"
3 Réponses :
Vous pouvez utiliser Héritage multi-table
Vous définissez Un objet de base, et de là, vous pouvez définir différents objets enfant qui partageront les propriétés des parents p>
dans votre cas qui ressemblerait à ceci: P>
class Object(models.Model): ... class Restaurant(Object): seats = IntegerField(...) reservations = ManyToManyField(...) class Hotel(Object): rooms = IntegerField(...) has_pool = BooleanField(...)
Hmm, a l'air très agréable, mais en ce moment, je ne peux pas vérifier cette solution, alors ne peut toujours pas accepter cette réponse, mais vous avez mon uppote pour le moment :)
Ok, ça marche bien. Une autre question, maintenant cela fonctionne avec une liste déroulante (choisissez la catégorie, envoyer AJAX à Views.py et dépend de param (catégorie) Afficher un formulaire différent pour chaque catégorie via un étui de commutation (si l'instruction de Python) est une façon plus intelligente de montrer différentes formes ?
Peut-être ajouter un champ form_class aux différents modèles? Ensuite, vous pouvez simplement appeler le formulaire de l'objet, quelque chose comme form_class = restaurantform code>
Oui, mais alors chaque restaurant l'aura, il y aura une répétition. De plus, si je veux l'automatiser (si je crée des liens pour chaque catégorie, comme maintenant et appelez des objets pour chaque catégorie, je devrais maintenant utiliser si la déclaration)? Le problème majeur est que je ne peux pas séparer différentes catégories maintenant (car ils n'ont pas unique, comme catégorie_id ou autre chose)
L'utilisation d'une classe de base abstrait ne vous permet pas d'interroger tous les "objets", non?
Ce n'est pas, tu as raison, mais c'était une exigence de @morganfreefarm?
Je ne sais pas, juste vérifier;)
Je vais expliquer celui-ci par un: p> blockQuote>
catégorie code> La table contient toutes les catégories. li>
- Il peut exister une fonctionnalité commune et unique pour chaque catégorie.
Caractéristiques CODE> aura
Beaucoup de relations code> avec
catégorie code> Tableau.
Nous créons donc une tableFeature_MASTER CODE> et nous le ferons mapper avec la table de catégories. LI>
Feature_Master CODE> La table contient toutes les fonctionnalités. li>
catégorie_feature_map code> La table est la table de la carte (table de jonction) li>
Object CODE> TABLE portez tous les détails sur l'objet et
objet_detail code> Table contiendra la totalité de la fonctionnalité
code> à un objet particulier li> ul>
Merci de cette réponse, mais de Django Development View, je pense que les solutions ci-dessus sont meilleures :)
DB devrait être indépendant de O.R.M. toujours. Donc, si dans le temps, nous voulons changer le cadre, nous n'aurons pas à vous soucier de la base de données. DB devrait être indépendant de l'ormes toujours
Je suggérerais de lire cet article! Cela pourrait vous donner une bonne inspiration pour votre cas d'utilisation!
https://realpython.com/modeling-polymorphism-django-python/ code>