0

Я хочу сопоставить эти таблицы с Hibernate:самостоятельной ссылки Entity в спящем режиме с помощью дополнительных столбцов

CREATE TABLE user 
(
    id VARCHAR(20), 
    //some stuff  
    PRIMARY KEY(id) 


); 

CREATE TABLE friendship 
(
    user1 VARCHAR(20), 
    user2 VARCHAR(20), 
    firstMeeting TIMESTAMP, 
    //mb some additional stuff 
    PRIMARY KEY(user1, user2), 
    FOREIGN KEY(user1) REFERENCES user(id), 
    FOREIGN KEY(user2) REFERENCES user(id) 
); 

Интересно, о правильном пути к карте это. Я думал об этом:

объект пользователя с

@ManyToMany Set<Friendship> friendships; 

Дружба entitiy с

@Size(min=2, max=2) 
@ManyToMany Set<User> members; 

Date firstMeeting; 

, но я не думаю, что это соответствует схеме выше (не только в столбце имен, но в счете TBL, то для схемы требуется 2, но для этого потребуется 3 таблицы, сопоставленные, 2 сущности и 1 для таблицы сопоставления отношений ManyToMany). problm это я не могу сопоставить это как 2times

@ManyToOne User user1/2; 

, потому что тогда я не смогу перенаправить дружбу с пользователем, потому что я не могу добавить что-то вроде

@OneToMany Set<Friendship> friendships; 

для пользователя, потому что я не буду в состоянии указать mappedBy =? аргумент, поэтому отношение будет отображаться в дополнительной таблице ...

НО, но я хочу сохранить его двунаправленным.

Любое хорошее решение этой проблемы?

Кроме того, не имеет значения, как пользователи заказываются в таблице дружбы, поэтому (user1, user2) = (user2, user1). Я думаю, что это лучше всего выразить в idClass/EmbeddedId с эквивалентом equals() - Реализация, правильно?

EDIT: кажется возможным АРХИВ это, если и определить некоторый порядок в течение 2-х элементов, как из < -> к, владелец < -> принадлежит, но я не вижу какой-либо естественный порядок в этом отношении и Я не хочу, чтобы Rly определить некоторые искусственные вещи, только для этого технического вопроса ...

ответ

0

объекта пользователя с

@ManyToMany Set<Friendship> friendships; 

, а затем дружбы таблицы:

User member; 
User memberFriend; 
Date firstMeeting; 

или если вы хотите Friendship entitiy с PRIMARY KEY (user1, user2), компания должна быть разделена на 2 таблицы, как:

FriendFK fKey; 
Date firstMeeting; 

и стол FriendFK:

User member; 
User memberFriend; 
+0

это привело бы к 3 таблицы : 1) дружба 2) пользователь 3) friendship_user (см. Вопрос) – scrimau

+0

кроме того, вам не нужно создавать дополнительную сущность для создания составного pk. Существуют и другие способы достижения этого (IdClass или EmbeddedId). – scrimau

 Смежные вопросы

  • Нет связанных вопросов^_^