Как избежать Отношения «Мой отец - мой сын»

Question

Еще раз хочу попросить вас помочь мне в моем проекте.

Мое отношение Класс:

private GT_Member mother; 

private GT_Member father; 

private GT_Family ownerF; 

private List<GT_Member> children; 

Как я могу реализовать в Спринг приложении проверка родословная ?? Я бы хотел запретить отцу или дедушке одного человека в качестве его сына.

В клиентской кличке простая ситуация, я делаю фильтрацию списка. Но как это сделать в базе данных?

Answer 1

Создайте метод addChild и проверьте иерархию рекурсивно вверх, чтобы ребенок не был частью своей собственной родословной.

Как это:

public class GT_Member { 

    private final GT_Member mother; 

    private final GT_Member father; 

    private final List<GT_Member> children; 

    public GT_Member(final GT_Member mother, final GT_Member father) { 
     this.mother = mother; 
     this.father = father; 
     this.children = new ArrayList<>(); 
    } 

    /** 
    * Add a child to this member. 
    * @param child 
    */ 
    public void addChild(GT_Member child) { 
     if (child == null) { 
      throw new IllegalArgumentException("Null children not allowed"); 
     } 
     if (child.equals(this)) { 
      throw new IllegalArgumentException("Can't add self as a child"); 
     } 
     if (isAncestor(child)) { 
      throw new IllegalArgumentException("Can't add an ancestor as a child"); 
     } 
     children.add(child); 
    } 

    /** 
    * Check if a member is an ancestor to this member. 
    * @param member 
    * @return True if the member is an ancestor, false otherwise 
    */ 
    private boolean isAncestor(final GT_Member member) { 
     // Check if the member is the mother or father 
     return member.equals(mother) || member.equals(father) 
       // Check if the member is an ancestor on the mother's side 
       || (mother != null && mother.isAncestor(member)) 
       // Check if the member is an ancestor on the father's side 
       || (father != null && father.isAncestor(member)); 
    } 
} 

Answer 2

Я бы подошел к проверке на двух уровнях: 1. Проверка бизнес-логики в коде приложения. 2. Триггеры базы данных для обеспечения того, чтобы такие несоответствующие отношения не создавались/не обновлялись.