Unterschied bidirectional unidirectional

[Darky^]

Hallo

ich hab eine einfache Frage und zwar, was ist der unterschied zwischen einer

bidirectionalen one to one relationship und einer unidirectionalen one to one relationship im speziellen bei Entity Klassen.


Mfg

 

[SlaterB]

hast du zu beiden Begriffen keine Vorstellung?
wenn du nur einen davon kennst, ergibt sich das andere als Unterschied fast automatisch?

 

[Gregorrr]

bi = zwei
direktion = Richtungen
uni = eine/einfach

 

[ARadauer]

unidirektional: schüler kennen ihren lehrer, lehrer kennt schüler nicht
bidirektional: schüler kennen ihren lehrer, lehrer kennt seine schüler


zb
public class Schühler{

private Lehrer lehrer;
usw...
}

bei bidirektinal hat der lehrer auch sowas

public class Lehrer{
private List<Schühler> schüler;
usw.....
}

 

[bygones]

Schühler

klasse dass du dazu gerade ein Schulbeispiel genommen hast

 

[SlaterB]

private List<Schühler> schüler;

muss man erstmal zu tippen schaffen
nun aber genug gespammt

 

[ARadauer]

Dass das Absicht war, glaubt mir jetzt keiner oder? ;-)

 

[Tomate_Salat]

Dass das Absicht war, glaubt mir jetzt keiner oder? ;-)

kurze Antwort: ne
lange antwort: nein

 

[Darky^]

Ein Arbeitsauftrag (WorkOrder) umfasst mehrere Arbeitsgänge (TimeSlots), die mit einer
bestimmten Maschine (Machine) durchgeführt werden, und eine Start- bzw. Endzeit
haben.

was für Beziehungen wären das?

 

[SlaterB]

das kann man so oder so machen, das ist von der Fachlichkeit unabhängig,
die gibt höchstens die Unterscheidung n:1 oder n:m (edit: sowie 1:1) vor, ob uni- oder bidirektional ist aber eine reine Implementierungsfrage

WorkOrder kennt eine Liste von Timeslots oder Timeslot kennt einen Workorder,
oder eben beides gleichzeitig

 

[IH]

Ist das Beispiel mit dem Lehrer/Schüler wirklich so passend?
Wenn ich das richtig verstanden habe, ging es hier nur um OneToOne-Beziehungen

Ich dachte bis jetzt, dass der Unterschied ob uni- oder bi-direktional sich daraus ergibt, über wen die Beziehung gesteuert wird..
Beispiel: Ein Schüler kann nur ein Mathebuch haben und ein Mathebuch nur von einem Schüler besessen
werden

Unidirektionale Lösung: Man kann entweder dem Schüler das Mathebuch geben "Schüler.setMathebuch()"
oder das Mathebuch dem Schüler zuordnen "Mathebuch.setSchüler()"

Bidirektionale Lösung: Man kann beides, die Beziehung wird also von beiden bestimmt

In der Datenbank selbst ergibt sich daraus kein Unterschied. Stellt sich die Frage ob man auf die Bidirektionalität nicht einfach verzichten könnte. Nein - das merkt man schnell wenn man sich tatsächlich den komplizierteren Relationships zuwendet.
Beispiel OneToMany: -Ein Schüler kann nur an einer Schule sein
-Eine Schule kann viele Schüler haben

Unidirektionale Lösung:
class Schule{
// Keine Liste für die Schüler
}

class Schueler{
@ManyToOne
Schule schule
}

Folge: Kein Unterschied in der Datenbank
Vorteil: die Beziehung wird immer nur von einer Seite gepflegt sodass es einfach ist, die Daten
persistent zu halten,
Nachteil: jedoch tatsächliches handling im Code schwieriger, weil jedesmal dynamisch Abfragen
über den EntityManager auf der DB ausgeführt werden müssen

Bidirektionale Lösung
class Schule{
@OneToMany(mappedBy="schule")
List<Schueler> schueler;
}

class Schueler{
@ManyToOne
Schule schule
}

Folge: Kein Unterschied in der Datenbank
Nachteil (scheinbar): komplizierteres Mapping und das Pflegen muss von beiden Seiten erfolgen,
damit die Persistenz (Stimmigkeit oder so) der Daten sichergestellt ist
Vorteil : EntityManager weiß über die Beziehung bescheid: Leichteres Handling, da die
Daten über die Mappings im Hauptspeicher der VM vorgehalten werden (so in
der Art) >> Interaktion mit der DB kann so minimiert werden
Die Mühe lohnt sich =)

Ich persönlich würde immer Bidirektional wählen.

Falls was davon falsch war >> Korrektur erwünscht *gg*