Können zwei Tabellen gegenseitig zu einander in Beziehung stehen?

[AlexII]

Hallo,

können zwei Tabellen (A, B) gegenseitig zu einander in Beziehung stehen? Ein FK der Tabelle A zeig auf die Tabelle B, und der FK der Tabelle B zeigt auf die Tabelle A? Oder ist das keine gute Idee?

Danke!

[Dejan Vu]

Kommt drauf an. Normalerweise ist das ein Indiz, das etwas am Design faul ist, muss aber nicht. Nenn mal ein konkretes Beispiel.

[AlexII]

Tabelle Alarm
---------
id
alarmdatetime
fk_jobid


Tabelle Job
---------
id
job
fk_alarmid


Nun ist es so, mehrere Alarme können auf einen Job verweisen dazu der FK. Und den FK in der Tabelle Job brauche ich um alle Alarme aus der Tabelle Alarm zu löschen falls ein Job gelöscht wird.

[mkinzler]

Ich würde hier mit einer Zwischentabelle arbeiten.
Aber die Rückverknüpfung ist eigentlich nicht notwendig

SQL-Code:

Delete from alarm a where a.<pk> in ( select j.<pk> from job j where j.<fk> = a.<pk>);

[AlexII]

Ok...

[RoadR69]

mehrere Alarme können auf einen Job verweisen und wenn ich einen Job lösche, muss ich ebenfalls zugehörige Alarme löschen. Ist das DB-technisch gesehen nicht die gleiche Beziehung, will heißen, der FK in Jobs, der ja nur auf ein Elemant in Alarm zeigen könnte ist eh überflüssig?

[jobo]

Zitat:

Zitat von RoadR69 (Beitrag 1301194)

der FK in Jobs, der ja nur auf ein Elemant in Alarm zeigen könnte ist eh überflüssig?

Wenn dieser FK auf den einen Alarm keine spezielle Semantik hat, ist er mehr als überflüssig. Die Abhängigkeit kann aus den FK in Alarm gebildet werden.

Angenommen, man hätte sowas wie "Roter Alarm", der pro Job nur einmal vorkommen kann und dessen Eigenart unabhängig von den Merkmalen der gesamten Alarmliste je Job ist, könnte man sowas vielleicht gebrauchen.

[Dejan Vu]

Also pro Job mehrere Alarme? Ok, also der FK in der Alarmtabelle auf die Jobs. Klar.
Aber wozu hat dann ein Job eine Alarm-FK? Zum Löschen *aller* Alarme, wo die FK_AlarmID doch nur auf einen Alarm zeigt? Verstehe ich nicht.

Löschen eines Jobs 'JID'

Code:

delete from Alarme where FK_JobID='JID'
delete from Job where ID = 'JID'

Hab ich da was falsch verstanden?

[AlexII]

Ne, ist schon richtig so, alles richtig verstanden... danke! :thumb:

[khh]

eine gute Gelegenheit sich mal hiermit zu beschäftigen ;-)
https://www.hdm-stuttgart.de/~rieker...kelz/chap4.htm

[Dejan Vu]

Jaaaa, passt hier nicht (imho). Ich glaube, hier wurde einmal zu viel um die Ecke gedacht, das ist alles.

Aber grundsätzlich: Pflichtlektüre.

[Perlsau]

Zitat:

Zitat von AlexII (Beitrag 1301191)

Nun ist es so, mehrere Alarme können auf einen Job verweisen dazu der FK. Und den FK in der Tabelle Job brauche ich um alle Alarme aus der Tabelle Alarm zu löschen falls ein Job gelöscht wird.

Mal ganz langsam: Es gibt eine Job-Tabelle, die hat einen PK (Primary Key). Und es gibt eine Termin-Tabelle, da gibt es neben der Spalte DATUM ebenfalls einen PK. Nun möchtest du notieren, daß ein Job mehrere Termine haben kann, ein Termin aber auch mehrere Jobs. Dafür erstellst du nun eine dritte Tabelle, die meinetwegen JOB_TERMIN heißt, spendierst ihr einen PK und richtest daneben noch die Spalten Id_Job und Id_Termin ein. In diese dritte Tabelle schreibst du nun deine Zuweisungen:

Delphi-Quellcode:

Function NeuerTermin(Const Id_Job, Id_Termin : Integer) : Boolean;
begin
  Id_Job := Query_Job.FieldByName('ID_JOB').AsInteger;
  Id_Termin := Query_Termin.FieldByName('ID_TERMIN').AsInteger;
  If Not Query_Job_Termin.Locate('ID_JOB;ID_TERMIN';VarArrayOf([Id_Job,Id_Termin]),[]) Then
  Begin
    Query_Job_Termin.Append;
    Query_Job_Termin.FieldByName('ID_JOB').AsInteger := Id_Job;
    Query_Job_Termin.FieldByName('ID_TERMIN').AsInteger := Id_Termin;
    Query_Job_Termin.Post;
    Result := True;
  End Else Result := False;
end;

Auf diese Weise kannst du nun jedem Termin mehrere Jobs zuweisen und jedem Job mehrere Termine. Wenn du nun einen Job löschen willst, dann merkst du dir dessen Id und löschst aus der Tabelle JOB_TERMIN alle Einträge, die sich auf diese Job-Id beziehen.

[Dejan Vu]

Ich glaube nicht, das er meint, das ein Termin mehrere Jobs haben kann. Wenn doch (m:n-Beziehung), hättest Du Recht.

[p80286]

Zitat:

Zitat von Dejan Vu (Beitrag 1301274)

Ich glaube nicht, das er meint, das ein Termin mehrere Jobs haben kann. Wenn doch (m:n-Beziehung), hättest Du Recht.

Wäre es ausgeschlossen, daß eine n:m Beziehung bestehen könnte, dann wäre eine solche Tabelle unnötig.

Gruß
K-H

[Perlsau]

In der Tat! Dann würde nämlich eine Tabelle mit den Spalten Termin und Job-Id vollauf genügen. Wenn dies das Anliegen des TE wäre, bräuchte er keine zusätzliche Tabelle. Es gibt sogar Grund zu der Vermutung, daß der TE das so gemeint haben könnte, denn er wollte in seiner DB-Unerfahrenheit ja lediglich die einem Job zugehörigen Termine löschen, wenn der Job gelöscht wird, und glaubte, er müsse dafür irgendwie in der Job-Tabelle vermerken, welche Termine jeder Job habe, obwohl diese Information ja bereits in der Termine-Tabelle notiert wurde. Er wußte nicht, daß man das einfach via SQL-Befehl erledigen könnte:

delete from TERMINE where ID_JOB = ...
delete from JOBS where ID_JOB = ...

[Dejan Vu]

Zitat:

Zitat von p80286 (Beitrag 1301286)

Zitat:

Zitat von Dejan Vu (Beitrag 1301274)

Ich glaube nicht, das er meint, das ein Termin mehrere Jobs haben kann. Wenn doch (m:n-Beziehung), hättest Du Recht.

Wäre es ausgeschlossen, daß eine n:m Beziehung bestehen könnte, dann wäre eine solche Tabelle unnötig.

D.h. Du gibst mir Recht.

Zitat:

Zitat von Perlsau (Beitrag 1301303)

..daß man das einfach via SQL-Befehl erledigen könnte:...

Hatten wir auch schon

Zitat:

Zitat von Dejan Vu (Beitrag 1301196)

Löschen eines Jobs 'JID'...

Wer hört auf erstes auf, dem Vorposter Recht zu geben? ;-) Ich meine, es ist Balsam für die Seele, aber spamt auf Dauer das Forum zu :lol:

[Perlsau]

Zitat:

Zitat von Dejan Vu (Beitrag 1301306)

Wer hört auf erstes auf, dem Vorposter Recht zu geben? ;-) Ich meine, es ist Balsam für die Seele, aber spamt auf Dauer das Forum zu :lol:

:?: :?: :?:

[Dejan Vu]

Na, Du sagst was Richtiges. Ich sag was, KH gibt mir Recht, Du gibst mir Recht (wiederholst das, was ich eine Seite zuvor gesagt habe). Ist ja alles kein Problem, aber irgendwie drehen wir uns im Kreis. Die Lösungen aller Lösungen ist schon genannt (keine m:n Beziehung, FK in den Terminen unnötig, Löschen über zwei DELETE-Befehle).

Jetzt können wir endlos darauf herumreiten und uns gegenseitig Recht geben, oder etwas anderes machen. Ich plädiere für Letzteres.

:!::!::!::!::!::!::?:

[AlexII]

Also ein Job kann mehrere Alarme haben, z.B. jeden Mittag um 12 Uhr, oder nur ein Mal. Und ein Alarm kann nur auf einen Job zeigen. Ist wohl ne 1:n Beziehung.

[p80286]

Zitat:

Zitat von Dejan Vu (Beitrag 1301306)

Zitat:

Zitat von p80286 (Beitrag 1301286)

Zitat:

Zitat von Dejan Vu (Beitrag 1301274)

Ich glaube nicht, das er meint, das ein Termin mehrere Jobs haben kann. Wenn doch (m:n-Beziehung), hättest Du Recht.

Wäre es ausgeschlossen, daß eine n:m Beziehung bestehen könnte, dann wäre eine solche Tabelle unnötig.

D.h. Du gibst mir Recht.

Leider Nein! da in unseren Aussagen die Schwerpunkte diametral sind.
Durch

Zitat:

Zitat von AlexII (Beitrag 1301325)

Also ein Job kann mehrere Alarme haben, z.B. jeden Mittag um 12 Uhr, oder nur ein Mal. Und ein Alarm kann nur auf einen Job zeigen. Ist wohl ne 1:n Beziehung.

Hat sich allerdings die Diskussion über n:m Relationen erledigt.

Gruß
K-H

[Photoner]

Zitat:

Zitat von Dejan Vu (Beitrag 1301310)

Na, Du sagst was Richtiges. Ich sag was, KH gibt mir Recht, Du gibst mir Recht (wiederholst das, was ich eine Seite zuvor gesagt habe). Ist ja alles kein Problem, aber irgendwie drehen wir uns im Kreis. Die Lösungen aller Lösungen ist schon genannt (keine m:n Beziehung, FK in den Terminen unnötig, Löschen über zwei DELETE-Befehle).

Jetzt können wir endlos darauf herumreiten und uns gegenseitig Recht geben, oder etwas anderes machen. Ich plädiere für Letzteres.

:!::!::!::!::!::!::?:

Delphi-Quellcode:

procedure DuHastRecht(const WahrOderFalsch : Boolean);
begin
  if WahrOderFalsch then begin
    Writeln('Du hast recht');
    DuHastRecht(WahrOderFalsch);
  end;
end;

Ich plädiere auch für Letzteres. Denn die erste Option ergibt einen Speicherüberlauf :stupid:.

[Dejan Vu]

Du hast Recht. :mrgreen:

[hstreicher]

vielleicht habe ich es überlesen , aber Foreign Keys können das löschen der anhängigen Records erledigen wenn man den FK mit ON DELERE CASCADE erzeugt

https://www.sqlite.org/foreignkeys.html

mfg Hannes