дизайнерского решения при использовании 12:59 отношений

Я следующие сущности, я в сомнении о дизайне конструкции, как следует DRIVING_LICENSE таблица содержит внешний ключ PERSON_ID или PERSON таблицы должна иметь LICENSE_NUMBER в качестве внешнего ключа из DRIVING_LICENSE таблицы?дизайнерского решения при использовании 12:59 отношений

Если PERSON таблица имеет LICENSE_NUMBER то PERSON таблица будет подчиненная таблица и DRIVING_LICENSE будет родительская таблица, поэтому это означает, что, когда водительские права удаляется, то человек должен быть удален.
С другим путем, если DRIVING_LICENSE будет PERSON_ID затем в уни направленного отношения один к одному в спящем режиме, мы не сможем иметь ссылку на DrivingLicense вместо этого мы будем иметь ссылку на Person в DrivingLicense, но большинство время, когда требуется, чтобы мы получили Person не DrivingLicense.

Выше двух моих основных сомнений? Каков правильный выбор и каковы его плюсы и минусы?

DrivingLicense.java 
@Entity 
@Table(name = "DRIVING_LICENSE") 
public class DrivingLicense { 
    @Id 
    @GeneratedValue(strategy = GenerationType.AUTO) 
    @Column(name = "LICENSE_NUMBER") 
    private int licenseNumber; 
    @Column(name = "DATE_OF_ISSUE") 
    private Date dateOfIssue; 

    @OneToOne 
    @JoinColumn(name = "PERSON_ID") 
    private Person person; 
}

Person.java 
@Entity 
@Table(name = "PERSON") 
public class Person { 
    @Id 
    @GeneratedValue(strategy = GenerationType.AUTO) 
    @Column(name = "PERSON_ID") 
    private int personId; 
    @Column(name = "PERSON_NAME", nullable = false, length = 30) 
    private String personName; 

    @OneToOne(mappedBy = "person", cascade = CascadeType.ALL) 
    private DrivingLicense drivingLicense; 
}

источник

2015-10-09 eatSleepCode

Ваше первое предположение неверно: при удалении водительских прав вы не должны удалять человека. Вам просто нужно установить личность человека в значение null. Ваше второе предположение также странно: отсутствие ссылки на водительские права в Person не имеет никакого отношения к тому, где находится внешний ключ. Это связано с тем, что вы явно решили сделать объединение однонаправленным. Но если естественная навигация от человека к водительским удостоверениям, то идите для первого. –

@ JBNizet еще одна проблема заключается в том, что если я пойду с 1-го предположения, тогда удаление человека будет хлопотно, потому что мне сначала нужно будет удалить водительские права, а затем лицо. Итак, что вы предлагаете, является хорошей практикой и с которой мне следует пользоваться при использовании однонаправленного OneToOne? – eatSleepCode

За свою жизнь у Prson может быть более одной водительской лицензии, например. Предварительное (во время обучения) и Полное после того, как они прошли. Или скажите водительское удостоверение такси. Независимо от того, как ваша модель действительно реализует эти детали, это не соотношение 1: 1. Более философски, лицо обращается за лицензией. Лицензия не существует перед приложением. Так что, как бы мы ни смотрели на это, PERSON является родительской таблицей, а LICENSE зависит. – APC

водительские права должны содержать NOT NULL внешний ключ к лицу с ограничением уникальности и вот почему:

Каждая лицензия необходимо быть связаны с человек.
Человек может иметь нулевойили одну лицензию, связанную с ними.

Поскольку лицензия должна быть связана с человеком, но лицо не нуждается в лицензии, внешний ключ должен храниться в таблице лицензий.

Уникальное ограничение на внешний ключ обеспечит соблюдение отношений «один-к-одному». Без этого у вас были бы отношения «один ко многим».

источник

2015-10-09 14:26:22 Sentinel

дизайнерского решения при использовании 12:59 отношений

ответ

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