Ich hatte ein ähnliches Problem wie in Wie kann man abstrakt-klassenbasierte Objekte in Django abfragen? Der Thread schlägt vor, multi_table_inheritance zu verwenden. Ich persönlich denke, dass content_type konzeptionell komfortabler ist (fühlt sich logischer an, zumindest für mich).
Unter Verwendung des Beispiels im vorherigen Link würde ich einfach einen Stelartyp als
hinzufügen %Vor%Fügen Sie das dann dem abstrakten Basismodell hinzu
%Vor%Um zwischen StellarObject und StellarType zu synchronisieren, können wir das post_save-Signal verbinden, um jedes Mal, wenn ein Planet oder Stern erstellt wird, eine StellarType-Instanz zu erstellen. Auf diese Weise kann ich StellarObjects über StellarType abfragen. Also ich würde gerne wissen, was ist die PRO und CON dieser Ansatz gegen die Verwendung von multi_table_inheritance verwenden? Ich denke, beide erstellen eine zusätzliche Tabelle in der Datenbank. Aber wie steht es mit der Datenbankleistung? Wie steht es mit Usability / Flexibilität? Vielen Dank für Ihre Eingabe!
ContentType ist für mich der richtige Weg, wenn Sie ein Objekt mit einem von vielen Modellen verknüpfen möchten, die nicht grundsätzlich denselben "Typ" haben. Zum Beispiel, wenn Sie Kommentare zu Benutzern, Seiten und Bildern in einem sozialen Netzwerk eingeben möchten, aber es gibt keinen vernünftigen Supertyp, den diese drei Modelle gemeinsam haben. Sicher könntest du einen "kommentarablen" Supertyp erstellen, aber für mich fühlt sich das eher wie ein Mix-In als ein grundlegender Typ an, aus dem diese drei Dinge abgeleitet sind. Bevor ContentType herauskam, hätten Sie keine andere Wahl gehabt, als Supertypen für diese Art von Beziehungen zu erfinden, die wirklich schnell hässlich werden können, wenn Sie es mehrmals in der gleichen Anwendung machen müssen (sagen wir, Sie haben auch Ereignisse, Warnungen, Nachrichten usw., von denen jede für eine andere Gruppe von Modellen gelten kann).
Die Vererbung mehrerer Tabellen ist am sinnvollsten, wenn Sie Attribute an das Basismodell anhängen möchten, sodass sie in allen konkreten Modellen, die sich davon erstrecken, gemeinsam verwendet werden, sodass Sie polymorphes Verhalten erhalten. Commentable passt nicht wirklich in diese Form, weil all dieses Verhalten auf das Kommentar-Modell, weniger auf die Commentable-Objekte angewendet werden kann. Wenn Sie jedoch unterschiedliche Klassen von Benutzern verwenden, die weitgehend dasselbe Verhalten aufweisen und aggregierbar sein sollten, ist dies viel sinnvoller.
Der Hauptvorteil der Multi-Table-Vererbung für mich ist ein saubereres Datenmodell mit impliziten Beziehungen und Vererbung, die auf der Python-Seite genutzt werden können (Polymorphismus ist immer noch ein wenig unordentlich, wie man sieht hier und hier ). Der Hauptvorteil von ContentType ist, dass es allgemeiner ist und Hilfsfunktionen aus Ihren Modellen heraushält, auf Kosten eines etwas weniger makellosen Schemas (viele "Meta" -Felder in Ihren Modellen, um diese Beziehungen zu definieren). Und für Ihr Beispiel müssen Sie sich immer noch auf post_save verlassen, was mir ebenfalls unnötig chaotisch / magisch erscheint.
Entschuldigung für die Wiederaufnahme des alten Threads. Ich denke, alles läuft auf die Lookup-Richtung hinaus. Ob Sie alle Unterklassen nach einem bestimmten FK durchsuchen (multiple Vererbung) oder die referenzierte Klasse als Inhaltstyp definieren und anhand der Tabellenreferenz und der ID (contenttypes) nachschlagen, macht keinen großen Unterschied in der Leistung - Hinweis: Sie beide saugen. Ich denke, Inhaltstypen sind eine gute Wahl, wenn Sie möchten, dass Ihre App leicht erweiterbar ist, d. H. Andere können neue Inhaltstypen hinzufügen, auf die verwiesen wird. Multitable ist gut, wenn Sie nur manchmal die zusätzlichen Spalten benötigen, die in zusätzlichen Tabellen definiert sind. Manchmal ist es auch eine gute Idee, alle Subtypen zusammenzuführen und nur eine zu machen, die einige Felder leer hat.
Tags und Links django django-models