2016-07-21 7 views
0

Ich benutze JPA Hibernate/Spring Boot, um einen Webserver mit MySQL-Datenbank zu erstellen, und ich versuche, eine POJO-Entität zu erweitern, die so aussieht zusätzliche OneToMany-Listen.JPA Hibernate :: Vererbung einer Entität mit zusätzlichen OneToMany-Listen

@Entity 
@Table(name="user") 
public class User { 
    @Id 
    @GeneratedValue 
    private Integer id; 

    @Column(nullable=false) 
    private String name; 

    ....Constructors, getters and setters.... 
} 

Mit dieser grundlegenden Benutzereinheit möchte ich nur eine UserInfo-Entität mit zusätzlichen Informationen über die Karriere des Benutzers erstellen.

@Entity 
public class UserInfo extends User { 

    @OneToMany(cascade= CascadeType.ALL, fetch= FetchType.EAGER) 
    @JoinColumn(name="user_id", referencedColumnName = "id") 
    private List<Career> careers; 

    ....Constructors, getters, setters...... 
} 

Und ich bin ziemlich verwirrt, welche Vererbungsstrategie ich wählen sollte. Ich denke nicht, dass es notwendig ist, dafür eine andere Spalte oder Tabelle zu erstellen. Oder sollte ich nur zweimal abfragen ..?

Ich bin irgendwie neu zu JPA so nicht sicher, welche als die beste Praxis oder Design angesehen wird ..

bearbeiten:

Dies ist, wie Karriere Unternehmen aussieht. Nur für den Fall ..

@Entity 
@Table(name="career") 
public class Career { 
    @Id 
    @GeneratedValue 
    private Integer id; 

    @Column(nullable=false) 
    private Integer user_id; 

    @Column(nullable=false) 
    private String name; 

    @Column(nullable=false) 
    private String description; 

    ....Constructors, getters and setters.... 
} 

Seit Benutzertabelle erstreckt bedeutungslos war (nur in meinem Fall), änderte ich die User Klasse wie folgt.

@Table(name="user") 
public class User { 
    @Id 
    @GeneratedValue 
    private Integer id; 

    @Column(nullable=false) 
    private String name; 

    @OneToMany(fetch= FetchType.LAZY) 
    @JoinColumn(name="user_id", referencedColumnName = "id") 
    private List<Career> careers; 

    ....Constructors, getters, setters...... 

} 

Jetzt versuche ich dies mit Spring Data JPA, und wenn ich versuche, um die Liste der Benutzer mit ihrer Karriere zu zeigen, ist es nun mehr als 40-mal etwa eine Minute Abfrage unter dem Ergebnis zu zeigen.

Ist das das N + 1 Problem ..? Wie kann ich das lösen?

+0

Sie verwenden derzeit die Zuordnung, indem Sie @OnetoMany über Ihr Careers-Element in der UserInfo-Klasse definieren. user_id sollte in User-Tabelle für die Zuordnung mit ID-Spalte der Career-Tabelle vorhanden sein. Ich sehe keine Notwendigkeit der Vererbungsstrategie (Es ist meine Ansicht obwohl) –

Antwort

0

Meiner Meinung nach liegt der Fehler im Modell selbst. Warum sollte UserInfoUser erweitern? Ich kann mir nicht vorstellen, welche Attribute oder Methoden die UserInfo von einer User erben soll. Typische Vererbungen wären "Entwickler" oder "Administrator".

Warum fügen Sie nicht UserInfo als eine 1: 1-Beziehung in Ihrer User Einheit? Eine andere Option ist UserInfo wegzulassen und die Career s als eine 1: n Beziehung rechts in Ihre User zu setzen.

Um mögliche n + 1 Probleme auf einer wachsenden Anzahl von Careers zu verhindern, möchten Sie vielleicht den Abrufmodus ändern. Siehe unten:

+0

Falls ich nicht für Career aber nur User abfragen müsste, dachte ich Es ist besser, eine hellere User-Entity und eine separate UserInfo-Entity zu erstellen, die größer sein kann. – user345

+0

Aus Gründen der Klarheit ist es absolut gültig, Daten von der Benutzerentität zu einer separaten UserInfo-Einheit zu übertragen. In Bezug auf Ihre Abfragen sollten Sie die Lazy-Loading-Strategie Ihres bestimmten JPA-Anbieters nutzen. – Matt

+0

Wenn ich eine user_info-Tabelle mache, wird es nur eine user_id-Spalte haben, die ein Fremdschlüssel der Benutzertabelle ist. Wenn ich die Karriere als eine 1: n-Beziehung in die Benutzertabelle bringe, würde es keine langsamere Leistung bringen, wenn ich nur nach 'ID' und 'Name' der Benutzereinheit suchen müsste? Ich bin verwirrt, welches das richtige Modell in diesem Fall wäre. – user345