Django Multi-Table Inheritance VS Explizite Angabe OneToOne-Beziehung in den Modellen

Hoffe das macht Sinn 🙂 werde ich klären, über Kommentare, falls nötig. Ich bin auch Experimentieren mit fettgedruckter text in dieser Frage, und wird es Bearbeiten, wenn ich (oder du) es als störend empfinden. Mit diesem aus dem Weg...

Mit django.contrib.auth gibt uns Benutzer und Gruppe, unter andere nützliche Dinge, die ich nicht machen kann, ohne (wie basic messaging).

In meiner app habe ich mehrere verschiedene Typen von Benutzern. Ein Benutzer kann nur einen geben. Das wäre leicht behandelt werden, indem Sie Gruppen, mit ein wenig extra-Pflege. Jedoch, diese verschiedenen Benutzer sind in Bezug auf einander in Hierarchien /Beziehungen.

Lassen Sie uns nehmen einen Blick an diesen Benutzer: -

Prinzipien - "top-level-Benutzer

Administratoren - jeder administrator meldet ein AUFTRAGGEBER

- Koordinatoren der einzelnen Koordinator berichtet an den Administrator

Abgesehen von diesen gibt es andere Benutzer gibt, die nicht direkt mit, kann aber für ähnliche, später. Zum Beispiel, "die Firma" ist eine andere Art von Benutzer, und kann verschiedene "Produkte", und Produkte können überwacht werden durch einen "Koordinator". "Käufer" ist eine andere Art von Benutzer kann Produkte kaufen.

Nun alle diese Benutzer haben verschiedene andere Attribute, von denen einige gemeinsam sind, alle Arten von Benutzern und einige von denen unterscheiden, die nur einem Benutzer geben. Zum Beispiel, alle Arten von Benutzern haben eine Adresse. Auf der anderen Seite, nur die Wichtigsten Benutzer gehört zu einer "BranchOffice".

Weiterer Punkt, der bereits oben angeführt, ist, dass ein Benutzer kann immer nur von einem Typ.

Die app auch Bedürfnisse zu verfolgen, erstellt und/oder modifiziert, Schulleiter, Administratoren, Koordinatoren, Unternehmen, Produkte etc.. (So dass zwei weitere links zu dem Benutzer-Modell.)

In diesem Szenario, ist es eine gute Idee, Django ' s multi-table inheritance wie folgt: -

from django.contrib.auth.models import User
class Principal(User):
    #
    #
    #    
    branchoffice = models.ForeignKey(BranchOffice)
    landline = models.CharField(blank=True, max_length=20)    
    mobile = models.CharField(blank=True, max_length=20)
    created_by = models.ForeignKey(User, editable=False, blank=True, related_name="principalcreator")    
    modified_by = models.ForeignKey(User, editable=False, blank=True, related_name="principalmodifier")
    #
    #
    #

Oder sollte ich gehen, es zu tun mögen dieses: -

class Principal(models.Model):
    #
    #
    #
    user = models.OneToOneField(User, blank=True)
    branchoffice = models.ForeignKey(BranchOffice)
    landline = models.CharField(blank=True, max_length=20)    
    mobile = models.CharField(blank=True, max_length=20)
    created_by = models.ForeignKey(User, editable=False, blank=True, related_name="principalcreator")    
    modified_by = models.ForeignKey(User, editable=False, blank=True, related_name="principalmodifier")
    #
    #
    #

Bitte beachten Sie, dass es andere Benutzer gibt, die über foreign keys, zum Beispiel: -

class Administrator(models.Model):
    #
    #
    #
    principal = models.ForeignKey(Principal, help_text="The supervising principal for this Administrator")
    user = models.OneToOneField(User, blank=True)
    province = models.ForeignKey(         Province)
    landline = models.CharField(blank=True, max_length=20)    
    mobile = models.CharField(blank=True, max_length=20)
    created_by = models.ForeignKey(User, editable=False, blank=True, related_name="administratorcreator")    
    modified_by = models.ForeignKey(User, editable=False, blank=True, related_name="administratormodifier")

Ich mir bewusst bin, dass Django nicht eine eins-zu-eins-Beziehung für multi-table inheritance hinter die kulissen. Ich bin einfach nicht qualifiziert genug zu entscheiden, was einem mehr sound Ansatz.

InformationsquelleAutor chefsmart | 2009-11-25

Ich würde gerne erweitern auf die Lösung von @thornomad.

Ausweitung der Django User-Klasse kann direkt dazu führen, dass alle Arten von Schwierigkeiten mit der internen django.auth-Mechanismen. Was ich getan habe, in einer ähnlichen situation ist genau das, was @thornomad schlägt - ich habe meine eigene UserProfile Modell verknüpften eins-zu-eins mit der Django-User-Modell, in dem hielt ich zusätzliche user-Daten und von dem ich geerbt Modelle für verschiedene Arten von Benutzern.

Etwas zu passen, was du beschrieben hast:

class UserProfile(models.Model):
    user = models.OneToOneField(User, blank=True, related_name='profile')
    class Meta:
        abstract = True


class PositionHolderUserProfile(UserProfile):
    first_name = models.CharField(max_length=30)
    last_name = models.CharField(max_length=30)
    landline = models.CharField(blank=True, max_length=20)    
    mobile = models.CharField(blank=True, max_length=20)
    created_by = models.ForeignKey(PositionHolderUserProfile, editable=False, blank=True, related_name="created_users")    
    modified_by = models.ForeignKey(PositionHolderUserProfile, editable=False, blank=True, related_name="modified_users")

class Principal(PositionHolderUserProfile):
    branchoffice = models.ForeignKey(BranchOffice)

class Administrator(PositionHolderUserProfile):
    superior = models.ForeignKey(Principal, related_name="subordinates")
    province = models.ForeignKey(Province)

class Coordinator(PositionHolderUserProfile):
    superior = models.ForeignKey(Administrator, related_name="subordinates")


class Company(UserProfile):
    name = models.CharField(max_length=50)

class Product(models.Model):
    name = models.CharField(max_length=50)
    produced_by = models.ForeignKey(Company)

class Buyer(UserProfile):
    first_name = models.CharField(max_length=30)
    last_name = models.CharField(max_length=30)
    products_bought = models.ManyToManyField(Product)

Das scheint wie eine gute Umsetzung für mich. Aber warum haben beide die UserProfile-Klasse und die PositionHolderUserProfile Klasse? Wird es nicht einfacher, um loszuwerden, diese und schieben Sie alles, was es zu dem ehemaligen model?
Ich dachte, es am besten einkapseln von Daten in Bezug auf alle Funktionsträger, z.B. Rektor, Administrator und Koordinator, aber nicht relevant für andere Nutzer wie Käufer und Unternehmen. Solche Daten könnten beinhalten, in welcher Branche Sie arbeiten, wie lange Sie schon berufstätig, etc.
Dies scheint nicht zu funktionieren mit den Einstellungen.AUTH_PROFILE_MODULE.
dies scheint nicht zu arbeiten.CommandError: One or more models did not validate: app1.positionholderuserprofile: Accessor for field 'user' clashes with related field 'User.profile'. Add a related_name argument to the definition for 'user'.
Django ' s-User-Modell hat sich stark verändert in den 4,5 Jahren seit ich dies geschrieben, Antwort!

InformationsquelleAutor taleinat

3

Ich habe vor kurzem umgeschaltet, um mit Hilfe von Modellen, die Erben aus der contrib.auto.Modelle.Benutzer. Meine Allgemeine Beobachtung ist, dass in der Theorie Sie sind groß, aber manchmal Sie nicht bekommen, die auto-magisch behandelt, wie Sie es sollten.

Ich denke, deine Entscheidung bezüglich der Vererbung vs. OneToOne kommt unten zu diesem:
- Möchte ich Django automatisch, etwas richtig machen 95% der Zeit, und Debuggen müssen, die anderen 5%
-ODER-
- Will ich etwas tun, manuell mich 100% der Zeit
Wenn du es noch nicht gesehen haben, die Scott Barham-blog hat einen tollen post zum Erben aus User-und auch den Aufbau einer speziellen back-end um sicherzustellen, dass Ihre benutzerdefinierten Objekt zurückgegeben wird -- Die Verlängerung der Django User.

Zusätzlich von Interesse wäre die AutoOneToOne Feld durch django-das nervt. Es ist eine Art hybrid der beiden Ansätze hier-es gibt keine Vererbung stattfindet, aber Django kümmert sich um die Erstellung der passenden OneToOneField wenn es nicht vorhanden ist.

Auch, thornomad macht einen guten Punkt, um die Redundanz in Ihren Modellen. Könnte man leicht implementieren Sie eine abstrakte Klasse zu sauber, als so (vorausgesetzt, du machst das Handbuch OneToOne):
```
class BaseExtendedUser(models.Model):
    user = models.OneToOneField(User, blank=True, related_name='profile')
    landline = models.CharField(blank=True, max_length=20)    
    mobile = models.CharField(blank=True, max_length=20)
    created_by = models.ForeignKey(User, editable=False, blank=True, related_name="created_users")    
    modified_by = models.ForeignKey(User, editable=False, blank=True, related_name="modified_users")

    class Meta:
        abstract = True

class Administrator(BaseExtendedUser):
    province = models.ForeignKey(Province)

class Principal(BaseExtendedUser):
    branchoffice = models.ForeignKey(BranchOffice)
```
- >aber manchmal Sie nicht bekommen, die auto-magisch behandelt, wie Sie es sollten. Könnte man erweitern auf diese und lassen Sie uns wissen, wie Sie sich nicht so Verhalten wie erwartet?
- Es ist schwer zu qualifizieren, aber die meisten Probleme sind mit dem contrib.admin, glaube ich. Gelegentlich treffen Sie seltsame Probleme, wie wenn Sie das überschreiben der AdminModel.model_save() habe ich gefunden (über eine Stunde+ Experimentieren), müssen Sie manuell festlegen, force_insert oder force_update sonst wird es nicht schaffen den passenden OneToOne. Gelegentlich die tatsächliche admin-interface Perücken aus und sagt, es ist bereits ein Datensatz vorhanden ist mit dieser ID, wenn Sie gerade aktualisiert gewissen Wert.
- Ich bin gonna haben zu schauen, dass, wenn das der Fall ist, aber ich bin nicht mit contrib.admin sowieso. Immer noch versuchen, herauszufinden, die vor-und Nachteile von Multi-Table Inheritance VS Explizite OneToOne Beziehung
InformationsquelleAutor T. Stone
2

Ich glaube nicht, dass ich Erben würde die User - Modell, sondern verwenden Sie eine benutzerdefinierte UserProfile - verlassen Sie die contrib.auth Modell allein. Mit dem custom UserProfile Modell, könnten Sie setup ein Basis Benutzer-Profil-Modell, das ein Teil sein kann von den verschiedenen Benutzer-Typen.

Schaut auf Sie schnell zu, ich würde genau hinschauen, alle Modelle, alle wiederholen die gleichen Felder (wie deine letzten zwei Principle und Administrator Modelle). Die Kombination der built in-Gruppen-Funktionalität, mit der Benutzer-Profil-Idee tun können, was Sie suchen.
- Es gibt andere Arten von Benutzern, die würde ich wirklich gerne getrennt halten. Wenn ich mir meine Modelle, ich würde gerne sehen, dass AUFTRAGGEBER, Administrator, Coordinator verbunden sind, aber auch, dass Unternehmen und Käufer sind nicht direkt mit dieser.
- Nur um zu klären, habe ich vor zu verwenden abstrakte Modelle, in denen vorteilhaft. Auch ich habe die Absicht, getrennte Modelle für unterschiedliche Typen von Benutzern.
InformationsquelleAutor thornomad
0

Bitte überlegen Sie, was passiert in den Daten-Modell, wenn ein Koordinator wird gefördert AUFTRAGGEBER. Würde ich nicht verwenden-Vererbung in diesem Fall. Bitte überdenken Sie die vorherigen poster Vorschlag "durch die Kombination von built in-Gruppen-Funktionalität, mit der Benutzer-Profil-Idee tun können, was Sie suchen."
- Es gibt keine Förderung stattfindet. "Durch die Kombination von built in-Gruppen-Funktionalität, mit der Benutzer-Profil-Idee tun können, was Sie suchen." ist eine gute übung, und ich Folge ihm, aber ich will wissen, was sind die vor-und Nachteile der Vererbung vs explizite onetoone in diesem speziellen Szenario...
InformationsquelleAutor user143112
0

Tun, müssen Sie die Objekte Ihrer Benutzer-Klassen zu handeln, wie ein auth.Benutzer überall? Das wäre der naheliegendste Grund für die Verwendung von Vererbung gegenüber OneToOne. Ein pro der OneToOne Ansatz wäre die Leichtigkeit, mit der Sie ändern können, zu einer anderen Benutzer-Modell, wenn das ein Anliegen ist.

Das wirkliche Problem sehe ich mit dem, was Sie haben oben (durch eine Methode) ist, dass es scheint nicht zu sein, nichts hindert Sie mit einem Principal-Objekt und ein Administrator-Objekt teilen die gleichen User. OneToOneField kann nur garantieren eine eins-zu-eins-Zuordnung zwischen zwei Beziehungen.
- Ich werde mit OneToOne jetzt weil ich genau weiß, was dort Los ist, anstatt zu erraten, all die Auswirkungen der Vererbung (wie der UserManager zum Beispiel). Mit mehr Kontrolle scheint wie ein guter Vorschlag.
InformationsquelleAutor mattucf

Schreibe einen Kommentar

Du musst angemeldet sein, um einen Kommentar abzugeben.