Является ли композитно-первичный ключ лучшим решением - Hibernate Spring - PullRequest
Новая
       10

Является ли композитно-первичный ключ лучшим решением - Hibernate Spring

0 голосов
/ 16 февраля 2019

Я создаю приложение чата для Spring, Hibernate и JPA, и мне нужны две таблицы - чаты и сообщения.В чате будет много сообщений, а также id и user_first и user_second.Прямо сейчас я делаю это с составным первичным ключом, где составной является user_first и user_second, а id является уникальным автоматическим приращением: 

public class ChatPK implements Serializable {
    protected int firstUser;

    protected int secondUser;
... 

@Entity
@IdClass(ChatPK.class)
@Table(name = "chats1")
public class Chat implements Serializable {
    @Id
    private int firstUser;

    @Id
    private int secondUser;

    @Column(name = "id", unique = true, nullable = false, insertable = false, updatable = false)
    @GeneratedValue(strategy= GenerationType.IDENTITY)
    private int id;
...

Есть ли лучший способ сделать это и почему?

Обновление: чат является уникальной строкой между двумя людьми, не может быть двух чатов с теми же двумя пользователями.Я хочу взять все нужные мне сообщения вместе с двумя пользователями, у которых были эти сообщения, чтобы я мог поместить идентификатор отправителя в ключ хэш-карты, а сообщения - в значение.К ответу ниже SessionId - это не то, что делает мой настольный чат, а не способ реализовать то, что я хочу.

1 Ответ

0 голосов
/ 16 февраля 2019

Нет, это не самый лучший.Основная роль первичного ключа заключается в обеспечении уникальности, вторичный - в быстром доступе.Ключи также используются для кеширования, поэтому размер вашего ключа определит, сколько вы также можете кешировать.Создание составного ключа означает, что вам нужно переопределить хэш-код и, возможно, равно.Вы слишком усложняете его.

Очевидно, что первого пользователя и второго пользователя недостаточно для придания уникальности вашему чату, потому что вы можете иметь много сеансов чатов между одними и теми же пользователями.

Я думаю, вам следует переименоватьВаш идентификатор для "sessionID" использует его в качестве первичного ключа и устанавливает две взаимосвязи между двумя пользователями за пределами первичного ключа. 

@Entity
@Table(name = "chats1")
public class Chat implements Serializable {
    @ManyToOne
    private User firstUser;

    @ManyToOne
    private User secondUser;

    @Id
    @Column(name = "sessionId")
    @GeneratedValue(strategy= GenerationType.IDENTITY)
    private int sessionId;
...

ОБНОВЛЕНИЕ: вопрос превратился в "за" и "против" составных ключей, который обсуждалсяПодробнее здесь Почему составные ключи не рекомендуются в спящем режиме?

...