django-REST: Verschachtelte Beziehungen vs PrimaryKeyRelatedField
Ist es besser geschachtelte Beziehungen oder das Feld PrimaryKeyRelated zu verwenden, wenn Sie viele Daten haben?
Ich habe ein Modell mit tiefen Beziehungen.
Der Einfachheit halber habe ich die Spalten nicht hinzugefügt.
Modell:
Anwendungsfall:
- Der Benutzer erstellt 1 Trainingsplan mit 2 Workouts und 3 WorkoutExercises.
- Der Benutzer erstellt 6 Sätze für jede Workoutübung / Übung.
- Der Benutzer beginnt mit dem Training & gt; neues FinishedWorkout wird erstellt
- Der Benutzer macht zuerst Übung und gibt die verwendeten Gewichte ein & gt; neue FinishedWorkoutExercise mit FinishedSet wird erstellt
Frage:
Ich möchte den Fortschritt für jeden Trainingsplan verfolgen & gt; Training & gt; Übung. Mit der Zeit hat der Benutzer vielleicht Dutzende von Trainings beendet, also Hunderte, wenn bereits Sets in der Datenbank sind.
Wenn ich jetzt verschachtelte Beziehungen verwende, kann ich viele Daten laden, die ich nicht brauche. Aber wenn ich PrimaryKeyRelatedFields verwende, muss ich alle Daten, die ich brauche, separat laden, was mehr Aufwand in meinem Frontend bedeutet.
Welche Methode wird in einer solchen Situation bevorzugt?
Bearbeiten:
Wenn ich PrimaryKeyRelatedFields verwende, kann ich unterscheiden, ob z. Workouts in Workoutplan sind ein Array mit Primärschlüsseln oder ein Array mit den geladenen Objekten?
2 Antworten
Wenn Sie PrimaryKeyRelatedField verwenden, haben Sie eine große Überladung, um die erforderlichen Daten im Frontend anzufordern.
In Ihrem Fall würde ich spezifische Serialisierer mit den gewünschten Feldern erstellen (mit Meta.fields attribut). Sie werden also keine unnötigen Daten laden und das Frontend wird nicht mehr Daten vom Backend anfordern müssen.
Ich kann einen Beispielcode schreiben, wenn Sie weitere Details benötigen.
Ich komme gleich zur Frage nach den Serialisierern, aber zuerst und zur Klarstellung. Was ist der Zweck, doppelte Modelle als Workout / Finished Workout, Set / Finished Set, ... zu haben?
Warum nicht ...
%Vor%Dann können Sie einfach ein fertiges Datum für ein Training festlegen, wenn es fertig ist.
Nun zur Frage. Ich würde vorschlagen, dass Sie über Benutzerinteraktionen nachdenken. Welche Teile des Front-Ends versuchen Sie zu füllen? Wie hängen die Daten zusammen und wie würde der Benutzer darauf zugreifen?
Sie sollten überlegen, mit welchen Parametern Sie DRF abfragen. Sie können ein Datum senden und erwarten, dass die Trainings an einem bestimmten Tag abgeschlossen sind:
%Vor%Viewset ...
%Vor%Und dann kann Ihr FinishedWorkoutSerializer einfach die gewünschten Felder für diesen bestimmten Abfragetyp haben.
Damit stehen Ihnen eine Reihe sehr spezifischer URLs zur Verfügung, was nicht besonders gut ist, aber Sie können spezifische Serializer für diese Interaktionen verwenden und Sie können den Filter auch dynamisch ändern, je nachdem, welche Parameter in% sind. co_de%.
Es besteht auch die Möglichkeit, dass Sie abhängig davon, welche Methode aufgerufen wird, unterschiedliche Filter verwenden möchten. Sie möchten beispielsweise nur aktive Übungen auflisten. Wenn ein Benutzer jedoch eine bestimmte Übung anfordert, möchten Sie, dass er auf diese Übung zugreift Das Exercise-Objekt sollte ein self.data -Attribut namens "active" haben.
Nun haben Sie verschiedene Objekte, die auf der gleichen URL angezeigt werden, abhängig von der Aktion. Es ist ein bisschen näher an dem, was Sie brauchen, aber Sie verwenden immer noch den gleichen Serializer. Wenn Sie also ein großes geschachteltes Objekt auf models.BooleanField benötigen, werden Sie auch eine Menge davon bekommen, wenn Sie retrieve() haben.
Um Listen kurz und verschachtelt zu halten, müssen Sie verschiedene Serializer verwenden.
Nehmen wir an, Sie möchten nur die Attribute list() und pk der Übungen senden, wenn sie aufgelistet sind, aber wenn eine Übung abgefragt wird, sollten Sie alle zugehörigen "Set" -Objekte in einem Array von "WorkoutSets" ...
Dann könnte Ihre serializers.py ein bisschen wie ... aussehen
%Vor%Ich werfe nur Anwendungsfälle und Attribute auf, die in Ihrem Modell wahrscheinlich keinen Sinn ergeben, aber ich hoffe, das ist hilfreich.
P. S .; Schau dir an, wie Java ich am Ende dort bekommen habe: p "ÜbungServiceExcersiceBeanWorkoutFactoryFactoryFactory"
Tags und Links django-rest-framework