Блог

Не могли бы вы, пожалуйста, объяснить мне это. Возьмем этот пример:

 public class Student
{
    public Student() { }

    public int StudentId { get; set; }
    public string StudentName { get; set; }

    public virtual StudentAddress Address { get; set; }

}

public class StudentAddress 
{
    [ForeignKey("Student")]
    public int StudentAddressId { get; set; }

    public string Address1 { get; set; }
    public string Address2 { get; set; }
    public string City { get; set; }
    public int Zipcode { get; set; }
    public string State { get; set; }
    public string Country { get; set; }

    public virtual Student Student { get; set; }
}
  

Я хочу понять, почему мы используем первичный ключ в зависимой таблице в качестве внешнего ключа, почему бы нам просто не следовать обычным способом: добавление внешнего столбца в зависимую таблицу, ссылающуюся на первичный ключ из основной таблицы?
И можем ли мы поменять роли здесь, т. Е. Использовать первичный ключ в сущности Student в качестве внешнего ключа?

Почему бы нам просто не последовать обычному способу: добавить внешний столбец в зависимую таблицу, ссылающуюся на первичный ключ из основной таблицы?

Если бы мы это сделали, связь была бы 1-n , а не 1-1 , поскольку у нас могло быть более одного StudentAddress с одинаковым значением этого поля. Используя первичный ключ в качестве внешнего ключа, мы гарантируем, что у нас не может быть более одного StudentAddress с одинаковым значением (это было бы нарушением первичного ключа). Таким образом, мы удостоверяемся, что реляционная ссылочная целостность выполняет всю работу за нас.

И можем ли мы поменять роли здесь, т. Е. Использовать первичный ключ в сущности Student в качестве внешнего ключа?

Тогда нам нужно сначала создать StudentAddress , а затем Student . Мы могли бы иметь a StudentAddress без наличия a Student . Как и сейчас, мы можем иметь a Student без каких-либо StudentAddress , но не наоборот. Я думаю, это имеет больше смысла. Это StudentAddress слабая сущность, что означает, что она не может существовать, если Student не существует корреспондента.

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