Это хорошая идея, чтобы использовать несколько отношений M2M между двумя объектами? - PullRequest
Новая
       63

Это хорошая идея, чтобы использовать несколько отношений M2M между двумя объектами?

0 голосов
/ 27 апреля 2020

У нас есть ситуация, когда нам нужно использовать два разных отношения M2M между двумя объектами в базе данных.

Объектами являются Users и Studies. Пользователи могут регистрироваться в исследованиях, но также могут иметь право для исследований.

Поэтому мы рассматриваем возможность моделирования этого с двумя различными таблицами: Enrollments и Eligibilities.

Схемы выглядят следующим образом:

  • Studies:
    • study_id PK
  • User
    • user_id PK
  • Enrollments:
    • enrollment_id PK
    • user_id FK
    • study_id FK
  • Eligibilities
    • eligibility_id PK
    • user_id FK
    • study_id FK

Мой вопрос: это хорошая идея? Я знаю, что это создаст две связи M2M между двумя объектами, когда рекомендуется объединить их в одну. Проблема при объединении этих отношений в одну таблицу заключается в том, что эти отношения независимы. Например, пользователь может иметь право на участие в исследовании и не регистрироваться, а пользователь может зарегистрироваться в исследовании, но не иметь права.

1 Ответ

2 голосов
/ 27 апреля 2020

Да, совершенно нормально; просто обратите внимание на ключи.

Я знаю, что это создаст две связи M2M между двумя сущностями, когда рекомендуется объединить их в одну.

Нет, это не так рекомендуется. Просто сосредоточьтесь на логике c, предикатах и ​​ограничениях, в отличие от жаргона (м2м ...). 

-- User USR exists.
--
user {USR}
  PK {USR}

-- Study STY exists.
--
study {STY}
   PK {STY}

-- User USR is eligible for study STY.
--
eligibility {USR, STY}
         PK {USR, STY}

FK1 {USR} REFERENCES user  {USR}
FK2 {STY} REFERENCES study {STY}

Если пользователь записался в исследование, то этот пользователь должен иметь право на участие в этом исследовании. 

-- User USR enrolled in study STY.
--
enrollment {USR, STY}
        PK {USR, STY}

FK {USR, STY} REFERENCES eligibility {USR, STY}

Примечание: 

All attributes (columns) NOT NULL

PK = Primary Key
FK = Foreign Key
...