Warum wird empfohlen, eine unidirektionale Eins-zu-viele-Verknüpfung auf einem Fremdschlüssel zu vermeiden?

Question

Mögliche Duplizieren:
Hibernate unidirectional one to many association - why is a join table better?

In der Hibernate-Online-Dokumentation unter Abschnitt 7.2.3 One-to-many, wird es erwähnt, dass:

unidirektionalen ein auf einem Fremdschlüssel ist ein ungewöhnlicher Fall, und wird nicht empfohlen. Sie sollten stattdessen eine Join-Tabelle für diese Art der Zuordnung verwenden.

Ich würde gerne wissen, warum? Das einzige, was mir in den Sinn kommt, ist, dass es beim Löschen von Kaskaden Probleme geben kann. Zum Beispiel bezieht sich Person auf eine Adresse in einer Eins-zu-Viele-Beziehung auf einem Fremdschlüssel, und die Adresse würde es ablehnen, vor der Person gelöscht zu werden.

Kann jemand den rationalen hinter der Empfehlung erklären? Hier

ist der Link zum Referenzdokument Inhalt: 7.2.3. One-to-many

Ich habe Kopie den eigentlichen Inhalt hier eingefügt:

Eine unidirektionale one-to-many-Vereinigung auf einem Fremdschlüssel ist ein ungewöhnlich Fall, und wird nicht empfohlen.

<class name="Person"> 
    <id name="id" column="personId"> 
     <generator class="native"/> 
    </id> 
    <set name="addresses"> 
     <key column="personId" 
      not-null="true"/> 
     <one-to-many class="Address"/> 
    </set> 
</class> 

<class name="Address"> 
    <id name="id" column="addressId"> 
     <generator class="native"/> 
    </id> 
</class> 

---

create table Person (personId bigint not null primary key) 
create table Address (addressId bigint not null primary key, personId bigint not null) 

Sie sollten stattdessen eine Join-Tabelle für diese Art von Vereinigung verwenden.

Answer 1

unidirektionale einer Eins-zu-viele Assoziations auf einem Fremdschlüssel ist ein ungewöhnlicher Fall, und wird nicht empfohlen.

Es gibt zwei Aspekte dazu:

• unidirektionale
• one-to-many

Die thread@CalmStorm ‚s gelöscht Antwort Links zu Adressen nur die zweite von diesen Dingen, aber fangen wir damit an.

Dieser Thread empfiehlt das Ersetzen von 1: n-Beziehungen mit Join-Tabellen, da sonst der Eins-zu-viele-Ansatz die vielen Seitentabellen mit Spalten füllt, die nicht zu dieser Entität gehören. porpuses (sic) '. Diese Taktik kann zu einem sauberen Modell in der Hibernate-Schicht führen, aber leider führt dies zu einer fehlerhaften Datenbank.

Da SQL nur bestätigen kann, dass der untergeordnete Datensatz ein übergeordnetes Element hat; Es gibt keine Möglichkeit, eine Regel durchzusetzen, dass der Elternteil ein Kind haben muss. Folglich besteht keine Möglichkeit, darauf zu bestehen, dass eine Tabelle Einträge in einer Join-Tabelle hat, was dazu führt, dass verwaiste Kinddatensätze möglich werden, die genau durch Fremdschlüssel verhindert werden sollen.

Ich habe mehrere andere Einwände, aber die nächste wichtigste ist Unangemessenheit. Schnittstellentabellen sollen Viele-zu-Viele-Beziehungen darstellen. Ihre Verwendung für die Darstellung von Eins-zu-Viele-Beziehungen ist verwirrend und erfordert zu viele zusätzliche Datenbankobjekte.

Also, zum zweiten Aspekt: ​​unidirektionale Eins-zu-viele-Assoziationen. Das Problem mit diesen ist die besondere Art und Weise, in der Hibernate sie standardmäßig behandelt. Wenn wir ein Eltern- und ein Kindelement in dieselbe Transaktion einfügen, fügt Hibernate den Kinddatensatz ein, fügt dann das Elternelement ein und aktualisiert das Kind mit dem Elternschlüssel. Dies erfordert aufschiebbare Fremdschlüssel-Constraints (yuck!) Und wahrscheinlich auch schiebbare Nicht-Null-Constraints (double yuck).

Es gibt ein paar Problemumgehungen. Eine besteht darin, bidirektionale Eins-zu-Viele-Verknüpfungen zu verwenden. Nach in the document you cite ist dies der gebräuchlichste Ansatz. Der andere Ansatz besteht darin, das Mapping des untergeordneten Objekts zu optimieren, aber das hat seine eigenen Auswirkungen.