Gutes Video! Verwendet man die Strategie Table, wenn man Fremdschlüssel in seiner Tabelle automatisch erzeugen möchte? (Also z.B. wenn bei MVC n zu m Relationen aufgelöst werden und eine Zwischentabelle erstellt wird)
Hallo Heinrich, vielen Dank für deine Frage. Angenommen du würdest, wie du beschreibst eine n:m-Relation haben, dann kannst du deine Objekte mit einer @ManyToMany-Annotation versehen. Zusätzlich gibt es die @JoinTable-Annotation um genau diese Zwischentabelle zu erstellen. Die Fremdschlüssel würden durch die JPA-Implementierung (z.B. Hibernate, EclipseLink,...,) "automatisch" generiert. Nun kommen wir zu den Strategien: Normalerweise ist es ja so, dass die Frameworks wie Hibernate eben die Datenbank-Technologien abstrahieren. Bedeutet, dass wir uns nicht mit den Spezifika einer Datenbank beschäftigen wollen und wir unabhängig von der Konkreten Datenbank(-Technologie) entwickeln wollen. Allerdings ist es nun so, dass bestimmte Aspekte nicht von jedem DBMS unterstützt werden. Bei Oracle kann nach meinem Kenntnisstand nicht die IDENTITY-Strategie verwendet werden. Um also die Abhängigkeiten von der konkreten Technologie zu reduzieren kann die TABLE-Strategie verwendet werden: Dort werden die IDs aus einer erzeugten Tabelle (mit IDs) abgelesen. Diese Strategie ist nach meinem Kenntnisstand nicht empfohlen.
Grundsätzlich lässt sich folgendes sagen: persist wird verwendet, wenn neue Daten anzulegen sind. Merge dient dem Update von Datensätzen, sprich du liest einen Datensatz aus der Datenbank, manipulierst diesen und speicherst diesen wieder in die DB. Das ist aber nur ein Teil der Wahrheit: Die Hauptfrage ist, was habe ich innerhalb einer Transaktionsklammer (vor dem Commit) mit den Objekten vor? Wenn ich die persist-Methode aufrufe und ein Objekt übergebe z.B. persist(Objekt1) und dann weiterhin Daten manipuliere (z.B. objekt1.setName("neuer Name")) dann wird nachdem persist der neue Name ("neuer Name") berücksichtigt und in der Datenbank gespeichert: em.persist(Objekt1) objekt1.setName("neuer Name") //Änderung wird in der DB berücksichtigt //Ende der Transaktion (trans.commit()) Beim merge würde diese Änderung nicht mehr berücksichtigt werden: merge(objekt1); objekt1.setName("neuer Name") //Änderung wird in der DB nicht mehr berücksichtigt //Ende der Transaktion (trans.commit())
Hi, schreib mir gerne eine E-Mail, dann könnte ich dir die Folien, sofern ich sie noch auf meiner ext. Festplatte habe, zur Verfügung stellen. Aktuell habe ich die Festplatte nicht bei mir.
Falls Dir das Video gefallen hat, freue ich mich auf Deine Unterstützung mit einem Abonnement!
Höchst interessantes Video für einen Programmierer wie mich. Danke dafür und gerne mehr!
Das freut mich zu hören. Vielen Dank für dein Feedback!
Extrem gute, verständliche und dennoch kompakte Erklärungen, vielen Dank!
Extrem gutes Feedback. Besten Dank 🌟
Gutes Video! Verwendet man die Strategie Table, wenn man Fremdschlüssel in seiner Tabelle automatisch erzeugen möchte? (Also z.B. wenn bei MVC n zu m Relationen aufgelöst werden und eine Zwischentabelle erstellt wird)
Hallo Heinrich, vielen Dank für deine Frage. Angenommen du würdest, wie du beschreibst eine n:m-Relation haben, dann kannst du deine Objekte mit einer @ManyToMany-Annotation versehen. Zusätzlich gibt es die @JoinTable-Annotation um genau diese Zwischentabelle zu erstellen. Die Fremdschlüssel würden durch die JPA-Implementierung (z.B. Hibernate, EclipseLink,...,) "automatisch" generiert. Nun kommen wir zu den Strategien: Normalerweise ist es ja so, dass die Frameworks wie Hibernate eben die Datenbank-Technologien abstrahieren. Bedeutet, dass wir uns nicht mit den Spezifika einer Datenbank beschäftigen wollen und wir unabhängig von der Konkreten Datenbank(-Technologie) entwickeln wollen. Allerdings ist es nun so, dass bestimmte Aspekte nicht von jedem DBMS unterstützt werden. Bei Oracle kann nach meinem Kenntnisstand nicht die IDENTITY-Strategie verwendet werden. Um also die Abhängigkeiten von der konkreten Technologie zu reduzieren kann die TABLE-Strategie verwendet werden: Dort werden die IDs aus einer erzeugten Tabelle (mit IDs) abgelesen. Diese Strategie ist nach meinem Kenntnisstand nicht empfohlen.
@@ModelMyMind Wow - Danke für die ausführliche Antwort! Super erklärt!
was ist der unterschied zwischen merge und persist
Grundsätzlich lässt sich folgendes sagen: persist wird verwendet, wenn neue Daten anzulegen sind. Merge dient dem Update von Datensätzen, sprich du liest einen Datensatz aus der Datenbank, manipulierst diesen und speicherst diesen wieder in die DB. Das ist aber nur ein Teil der Wahrheit: Die Hauptfrage ist, was habe ich innerhalb einer Transaktionsklammer (vor dem Commit) mit den Objekten vor? Wenn ich die persist-Methode aufrufe und ein Objekt übergebe z.B. persist(Objekt1) und dann weiterhin Daten manipuliere (z.B. objekt1.setName("neuer Name")) dann wird nachdem persist der neue Name ("neuer Name") berücksichtigt und in der Datenbank gespeichert:
em.persist(Objekt1)
objekt1.setName("neuer Name") //Änderung wird in der DB berücksichtigt
//Ende der Transaktion (trans.commit())
Beim merge würde diese Änderung nicht mehr berücksichtigt werden:
merge(objekt1);
objekt1.setName("neuer Name") //Änderung wird in der DB nicht mehr berücksichtigt
//Ende der Transaktion (trans.commit())
@@ModelMyMind vielen Dank für die rasche Antwort
Besteht die Möglichkeit, dass du uns die Folien zum Herunterladen zur Verfügung stellst? Würde mich riesig darüber freuen.
Hi, schreib mir gerne eine E-Mail, dann könnte ich dir die Folien, sofern ich sie noch auf meiner ext. Festplatte habe, zur Verfügung stellen. Aktuell habe ich die Festplatte nicht bei mir.
@@ModelMyMind Die Folien hätte ich auch gern. Danke für die Videos!
@@Stefan1971HH ich habe die Folien leider nicht mehr :/