BlackJack hat geschrieben:*Eine* Beziehung zu `auth.User` ist ja auch kein Problem, aber bei *zwei* führt das halt zu *zwei* Rückverweisen mit dem *gleichen* generierten Namen. An der Stelle muss man bei mindestens einer Beziehung manuell einen Namen für den Rückverweis geben. Am besten aber beiden, weil der automatisch generierte nicht wirklich gut die Beziehung ausdrückt. Oder man gibt an das gar keine Rückrichtung existieren soll, das geht natürlich auch.
@blackjack: Ich dachte mir das so:
Empfänger: user_id 1
Sender: user_id 3
Wozu benötigt man den related_name?
@DasIch: Danke, ich lasse die Bezeichnungen besser einmal drin. Ich verwende das Tutorial um mein Modell in Django zu transferieren.
@meego: Du willst vielleicht nicht nur von einer Nachricht wissen, wer sie geschickt hat, sondern von einem Member wissen, welche Nachrichten er alle geschickt hat. Daher gibt es Rückreferenzen. Die werden nicht im Datenbankschema als Felder abgebildet, sondern sind rein logisch. Django generiert automatisch eine Rückreferenz mit dem Namen der Ursprungstabelle. Wenn es aber zwei Rückreferenzen gibt, kann Django keinen automatisch (doppelt vergebenen) Namen vergeben.
@meego: Wenn man zwei Entitäten in Beziehung setzt hat diese Verbindung ja keine Richtung. Du gibst nur bei einer Klasse die Beziehung an, aber die Rückrichtung kann man ja auch abfragen. Und zwar auf den anderen Objekten über den `related_name`. Gehen wir mal davon aus das die Klasse für die Nachrichten `Message` heisst, dann wären die über das Attribut `messages` auf den `Member`-Objekten verfügbar, zumindest wenn es nur `sender` oder nur `receiver` gäbe. Wenn es beide gibt, dann gibt's genau das Problem aus der Fehlermeldung: es können nicht beide Rückrichtungen den gleichen Namen haben.
Die Tabellennamen sollten eher Einzahl sein, also `message` und `country`, denn genau wie eine Klasse beschreibt wie *ein* Exemplar aussieht beschreibt die Tabellendefinition wie *ein* Datensatz aufgebaut ist. Du solltest Dir vielleicht auch anschauen wie die Spaltennamen von Django generiert werden oder gleich einen UML-Entwurf der Modelklassen-Beziehungen erstellen und dort nicht die Spaltennamen sondern die Attributnamen verwenden. Im Moment sieht das entweder gemischt aus, oder Du hast keine einheitliche Namensgebung für Fremdschlüssel-Spalten.
@meego:
Dir ist schon klar, dass das Model `Member` nicht wie von Dir im Diagramm vorgesehen, mit Nachrichten verknüpft ist? Bzw. `Member` keine Beziehung zu `auth.User` hat. Mehr dazu https://docs.djangoproject.com/en/1.8/t ... user-model
Sirius3 hat geschrieben:@meego: Du willst vielleicht nicht nur von einer Nachricht wissen, wer sie geschickt hat, sondern von einem Member wissen, welche Nachrichten er alle geschickt hat. Daher gibt es Rückreferenzen. Die werden nicht im Datenbankschema als Felder abgebildet, sondern sind rein logisch. Django generiert automatisch eine Rückreferenz mit dem Namen der Ursprungstabelle. Wenn es aber zwei Rückreferenzen gibt, kann Django keinen automatisch (doppelt vergebenen) Namen vergeben.
@Sirius: Danke für die gute und schlichte Erklärung. Gibt es da eine Konvention zur Benennung?
BlackJack hat geschrieben:@meego: Wenn man zwei Entitäten in Beziehung setzt hat diese Verbindung ja keine Richtung. Du gibst nur bei einer Klasse die Beziehung an, aber die Rückrichtung kann man ja auch abfragen. Und zwar auf den anderen Objekten über den `related_name`. Gehen wir mal davon aus das die Klasse für die Nachrichten `Message` heisst, dann wären die über das Attribut `messages` auf den `Member`-Objekten verfügbar, zumindest wenn es nur `sender` oder nur `receiver` gäbe. Wenn es beide gibt, dann gibt's genau das Problem aus der Fehlermeldung: es können nicht beide Rückrichtungen den gleichen Namen haben.
Das ist mir jetzt klar. Das hier
Du solltest Dir vielleicht auch anschauen wie die Spaltennamen von Django generiert werden oder gleich einen UML-Entwurf der Modelklassen-Beziehungen erstellen und dort nicht die Spaltennamen sondern die Attributnamen verwenden. Im Moment sieht das entweder gemischt aus, oder Du hast keine einheitliche Namensgebung für Fremdschlüssel-Spalten.
Habe ich nicht ganz verstanden. Beüglich der Namensgebung, bin ich etwas gespalten, ob man da nicht besser eine einprägsame Bezeichnung eintippt (sender/receiver).
@meego: Du hast bei Deinen Spaltennamen für Fremdschlüssel mal Namen ohne Zusatz (`sender`), mal mit `id_`-Präfix und mal mit `_id`-Postfix. Ich würde an der Stelle den Datenbankentwurf mit dem ORM machen, denn Django hat da ja Konventionen wie die Spaltennamen zu den Attributen aussehen. Entweder hält man sich da dran oder man muss dann extra immer noch mal angeben wie das Attribut in der Datenbank heisst.
@meego:
Die Django-App django-extensions kann Dir aus den Modeldefinitionen auch ein ER-Diagramm zeichnen. Mit einem highly sophisticated ER-Diagramm würde ich nur an Django herantreten, wenn es die Datenlage nicht anders zulässt (z.B. bestehende legacy-DB, komplexe Relationen). Ansonsten würde ich zunächst versuchen, es so weit wie möglich mit den ORM-Boardmitteln abzubilden - das erspart Dir einiges an Kopfzerbrechen später auf Pythonseite. Schwierige oder schlecht mit dem ORM realisierbare Abfragen kannst Du dann immernoch per raw-Queries vornehmen.
@meego: Ich würde bei Verwendung eines ORM, das auch die Tabellen und Spalten erzeugen kann, kein Datenbank-Diagramm erstellen sondern ein Klassendiagramm. Das ist ja letztendlich die Ebene auf der man dann später auch arbeitet.
Ich denke für mich ist es in erster Linie auch ein Stück weit Auslegeordnung. Bloss aus den Klassen heraus kann ich mir manchmal schlecht vorstellen, wie das alles verknüpft werden soll.
Die Membertabelle (User) werde ich wohl erst einmal zurückstellen, weil sie offenbar Migrationsprobleme verursacht, wenn man sie falsch anlegt.
meego hat geschrieben:
Ich denke für mich ist es in erster Linie auch ein Stück weit Auslegeordnung. Bloss aus den Klassen heraus kann ich mir manchmal schlecht vorstellen, wie das alles verknüpft werden soll.
Wenn du ein ORM benutzt, dann solltest du dich halt auch darauf einlassen. Der Sinn des ORM ist ja, dass man sich eben _nicht_ mit der DB befassen musst.
Außerdem kannst du die Beziehungen doch auch im von blackjack vorgeschlagenen Klassendiagramm sehen.
Ein Freund hat mir mal auf Papier gezeigt, wie er von einer Idee über Skizzen zu einem Datenbankmodell kommt. Das war furchtbar einleuchtend und klar, aber online hab ich dazu noch keine guten Anleitungen gefunden.
MorgenGrauen: 1 Welt, 8 Rassen, 13 Gilden, >250 Abenteuer, >5000 Waffen & Rüstungen,
>7000 NPC, >16000 Räume, >200 freiwillige Programmierer, nur Text, viel Spaß, seit 1992.
Baut man so ein Portal eigentlich aus kleineren Apps auf oder macht man eine (irgendwie wäre es ja toll, wenn alle Model-Klassen an einem Ort definiert werden)?
