2014-01-30 1 views
1

Предположим, что у вас есть таблица выглядит следующим образом:Mapping ключи в JPA: Первичный ключ является внешним ключом

CREATE TABLE IF NOT EXISTS CREDENTIAL (
    USER_NAME  VARCHAR(20) NOT NULL, 
    HASHED_PASSWORD VARCHAR(128) NOT NULL, 
    CREATION_DATE  TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP, 
    LAST_UPDATE_DATE TIMESTAMP, 
    LAST_UPDATED_BY VARCHAR(20), 

    PRIMARY KEY (USER_NAME), 
    FOREIGN KEY (USER_NAME) REFERENCES USER(USER_NAME), 
    FOREIGN KEY (LAST_UPDATED_BY) REFERENCES USER(USER_NAME) 
) CHARACTER SET utf8; 

Можно видеть, что USER_NAME столбец является первичным ключом к таблице, а также внешний ключ. Да, MySQL успешно создает эту таблицу.

Вопрос прост, как я смогу сопоставить это в сущности JPA? Должен ли я иметь 1 идентификатор, который сопоставляется с столбцом USER_NAME и другим полем User user, которое объединяет столбец USER_NAME? Предложения приветствуются.

ответ

2

Простое решением будет:

@Entity 
public class Credential { 

    @Id 
    private String userName; 

    @ManyToOne 
    @JoinColumn(name = "user_name") 
    private User owner; 

    @ManyToOne 
    @JoinColumn(name = "last_modified_by") 
    private User lastUpdatedBy; 


} 

Примечания из собственного опыта:

Я бы рекомендовал создание surrogate primary key числового типа (полезный с точки зрения БД). Вы можете обеспечить уникальность имени пользователя по ограничению DB.

+0

Зачем использовать '@ ManyToOne'? Один пользователь имеет один учетный ключ, поэтому почему USER_NAME является первичным ключом. –

+0

ManyToOne намного проще в работе. Действительно, вы можете жить с OneToOne, но я считаю, что OneToOne будет сложнее управлять. Также, если приложение имеет несколько способов аутентификации пользователя? – WeMakeSoftware

+0

У этого есть, но другая схема аутентификации выполняется через их стороннюю аутентификацию, поэтому нет необходимости отображать ее на схеме '@ ManyToOne'. –