Hibernate OneToMany oder lieber OneToOne

[OnDemand]

Hallo zusammen,

habe grad die Überlegung ob ich meine Entity korrekt designed habe,

Habe ein Produkt zb Hose, dieses hat mehrere Eigenschaften (Größen, Farben)

Nun hat mein Produkt eine List mit Kombinationen als OneToMany

Aktuell macht mir das Problem, wenn eine neue Eigenschaft dazu kommt.

Könnten ich die beiden auch von einander lösen sodass ich auf Seiten der Eigenschaften mit OneToOne zu einem Produkt Mappe (statt wie jetzt auf Produktseite die Eigenschaften ran hänge?

Dann könnte ich wesentlich einfacher auf Änderungen reagieren, Produkte würden schneller laden, da die Eigenschaften nur dann geholt werden, wenn benötigt.

Gibts da eine Art Designvorschlag wann man OneToMany nutzt?

 

[Dukel]

Ist das bei dir aktuell so, dass es dann für jede Eigenschaft eine eigene Tabelle oder Spalte gibt?

 

[OnDemand]

Habe eine Tabelle combinations darin sind die Kombinationen gespeichert und

Grösse L Farbe Weiß

 

[mrBrown]

Hast du 'n DomänenModell dazu?


In meiner Vorstellung klappt das nur schwer mit OneToOne (=jedes Produkt hat eine Eigenschaft).
OneToMany/ManyToOne ist da schon sinnvoller, und mMn auch bei OneToMany auf Produktseite bleiben.

Deine Probleme verstehe ich noch nicht wirklich.
Eine neue Eigenschaft heißt doch einfach nur, eine Eigenschaft wird der Liste hinzugefügt?
Das Laden kann man kann man in beiden Fällen Lazy umsetzen.

 

[OnDemand]

Hab grad nix parat, aber das Problem ist folgendes. ich versuche es mal zu erklären.

Beim ersten Mal, wird das Produkt erstellt wenn es noch nicht in der DB vorhanden ist
Produkt wird erstellt, füge alle Eigenschaften und den Preis hinzu und speicher es ab. Nun ist es erstmal gespeichert und OK

Wenn sich nun die Menge ändert am Produkt, wird es wieder so gebaut und komplett abgespeichert, es wird dank @Dynamic.. nur die geänderte Menge ändern -> auch ok.

Nun kommt aber eine neue Eigenschaft dazu (der List geadded), wird die automatisch abgespeichert?

Irgendwie sehe ich keinen Sinn immer das gesamte Produkt zu bauen und zu speichern, wenn es nur eine neue Menge gibt (Daten kommen von einer API, dies nur als Info)

 

[mrBrown]

Um den Workflow zu verstehen: Du bekommst die Produktdaten von irgendwo her. Aus diesen erstellst du dann selbst ein neues Produkt-Objekt und speicherst dieses in der Datenbank?

Oder bekommst du neue Daten von irgendwo her, lädst das Produkt aus der Datenbank, änderst diese mit den bekommenen Daten und speicherst es dann ab?


Hibernates @DynamicUpdate (meinst du doch mit "@Dynamic.."?) funktioniert doch nur im zweiten Fall, im ersten ist ja gar nicht bekannt, welcheFelder sich geändert haben.

Und wenn du die zweiter Variante nutzt, kannst du einer Liste einfach ein Element hinzufügen und (wenns richtig konfiguriert ist) beim speichern wird dieses dann genau so in der Datenbank abgelegt.

 

[OnDemand]

Genau, ich bekomme die Daten von einer API, es ändert sich der Preis, Bestand und noch paar Dinge. Entweder sind die Produkte schon vorhanden in meiner DB oder die API gibt mir neue, also muss ich entweder updaten oder neu anlegen.

DynamicUpdate ist korrekt, mir fiel es nicht ein Das ändert den Preis wenn er sich geändert hat, richtig? Wenn er gleich ist, macht es nix

 

[mrBrown]

Genau, ich bekomme die Daten von einer API, es ändert sich der Preis, Bestand und noch paar Dinge. Entweder sind die Produkte schon vorhanden in meiner DB oder die API gibt mir neue, also muss ich entweder updaten oder neu anlegen.

Und das ist jetzt der erste oder der zweite von mir genannte Fall...?


Aber die einfachste Variante dürfte sein, dass mit OneToMany abzubilden, die neue Eigenschaft einfach dem Produkt hinzuzufügen und das Produkt dann zu speichern.

 

[OnDemand]

Aktueller Fall ist, so sollte es klappen oder:
Produkt mit 6 Eigenschaften schon vorhanden > wird komplett rausgeholt > nun die neuen Eigenschaften adden und speichern?

Noch eine davon unabhängige Frage:
Wie kann ich es verhindern, dass Hibernate den Preis updated? einfach keinen Preis setzen? Oder wie kann ich zur Laufzeit steuern, was updated werden soll?

 

[mrBrown]

Produkt mit 6 Eigenschaften schon vorhanden > wird komplett rausgeholt > nun die neuen Eigenschaften adden und speichern?

Jap.

Noch eine davon unabhängige Frage:
Wie kann ich es verhindern, dass Hibernate den Preis updated? einfach keinen Preis setzen? Oder wie kann ich zur Laufzeit steuern, was updated werden soll?

Die Antwort hast du dir doch schon selbst mit @DynamicUpdate gegeben?

 

[OnDemand]

Danke, mit dem Update ist es wie folgt:

Angenommen das Produkt hat einen Preis von 99 EUR

die API sagt jetzt aber, der neue Preis ist 89EUR

Der Kunde will es aber für 99EUR drin behalten. Ich habe einen "Schalter" im Frontend "Preise updaten Ja/Nein"
Wenn der Kunde da nein hat, darf der Preis nicht updated werden, muss also komplett übersprungen werden

 

[mrBrown]

Okay, dann überspring das Setzen des Preises doch einfach wie du sagst?

 

[OnDemand]

Super, das wollte ich hören also ist es dann NULL wenn es ein leerer String/Double sonst was ist, löscht es vermutlich den aktuellen Eintrag?

 

[mrBrown]

Warum sollte da irgendwas NULL sein?

 

[OnDemand]

Das Produkt hat zum Beispielein Objekt vom Typ Preis

private Preis preis;
//getter/setter

wenn ich nun setPreis() nicht aufrufe um das Produkt zu erstellen, ist es NULL

 

[mrBrown]

Ja, wenn vorher nichts da war, und du nichts setzt, bleibt nichts da.

Wenn aber vorher was da war, und du setzt nichts, bleibt da, was vorher da war.

 

[mihe7]

Irgendwie sehe ich keinen Sinn immer das gesamte Produkt zu bauen und zu speichern, wenn es nur eine neue Menge gibt

Du darfst bei der Verwendung eines ORM nicht in Datensätzen denken. Es geht um Objekte und der ORM bildet diese auf eine relationale DB ab.

Nehmen wir mal eine Rechnung. Die besteht aus einem Rechnungskopf und den Rechnungspositionen. Würdest Du jetzt sagen, dass die Rechnung nach dem Hinzufügen einer Rechnungsposition immer noch die gleiche ist? Wenn ja, dann lass mir Dir einen Euro in Rechnung stellen, ich füge dann noch ein paar Tausender in einer weiteren Rechnungsposition hinzu

Was Dein Modell angeht, ist das eine andere Sache. Das kann man pauschal nicht beantworten. Es könnte z. B. sein, dass "Menge" den Lagerbestand bzw. die Veränderung im Lager kennzeichnet. Das Lager hat mit dem Produkt "nichts" zu tun. Es ändert sich unabhängig von den Produkteigenschaften. Daher könnte es durchaus sinnvoll sein, überhaupt keine Objektbeziehung zu haben, sondern einfach über die IDs zuzuordnen.