Достаточно ли проверять в бизнес-логи c перед сохранением или я должен использовать триггеры для важных данных?

Question

У меня есть следующая модель класса:

I должен убедиться, что сотрудник имеет только одну роль, принадлежащую проект. Таким образом, если у проекта А есть роли roleA и roleB, то сотруднику разрешено иметь только одну из них (но ему, очевидно, разрешено иметь роль из другого проекта, но, опять же, только одну).

Я делаю уверен, что это всегда так в моей бизнес логи c. Поэтому перед тем, как добавить роль сотруднику, я проверяю, есть ли у сотрудника роль, принадлежащая проекту той роли, которую он хочет добавить, и т. Д. c. Поэтому, используя мой API / бизнес-логику c, я могу убедиться, что критерии must выполнены.

Но должен ли я добавить дополнительный уровень безопасности на уровне базы данных? Я мог бы добавить триггеры, которые проверяют вышеупомянутые критерии. Это сделало бы абсолютно невозможным добавление каких-либо данных в базу данных, которые нарушают мои критерии. Нужен ли этот дополнительный уровень безопасности на уровне базы данных или этого достаточно, если я выполню проверку в моей бизнес-логи c? И является ли триггер правильным лучшим способом сделать это?

Редактировать:

Я реализую то, что в комментариях предлагается следующим образом:

Мой IdClass реализация:

@Data
public class TestId implements Serializable {
  private Project project;

  private Employee employee;
}

Класс, реализующий троичную ассоциацию, делающий пару сотрудника и проекта уникальной:

@Entity
@Data
@IdClass(TestId.class)
public class Test {

  @Id
  @ManyToOne
  private Project project;

  @Id
  @ManyToOne
  private Employee employee;

  @ManyToOne
  private ProjectEmployeeRole projectEmployeeRole;
}

Answer 1

В одном вопросе два.

База данных : если вы хотите, чтобы база данных обеспечивала соблюдение этого правила, вам не нужен триггер. Просто реализуйте отношение «многие ко многим» между Employee и Project, используя таблицу ассоциации с первичным ключом, состоящим из EmployeeId и ProjectId: комбинация должна быть уникальной. В таблице связей вы также сохраните единственную роль, которую этот сотрудник будет выполнять в данном конкретном проекте.

Диаграмма классов UML: ваша диаграмма вводит в заблуждение, поскольку существует множество ассоциаций "многие ко многим", но, к сожалению, вы говорите, что одна конкретная роль может появиться только в одном проекте. Более ясный способ представить это в UML - представить троичную ассоциацию (таблица ассоциаций, которую я упомянул для базы данных, фактически подтолкнула бы эту троичную ассоциацию). Другим вариантом будет использование класса ассоциации UML, и этот класс ассоциации может сам иметь связь с ролью.