Наследование моделей и нормализация БД в ядре - PullRequest
Новая
       12

Наследование моделей и нормализация БД в ядре

0 голосов
/ 07 декабря 2018

Выполнение C # ASP.NET Core 2.1 MVC и следование учебным пособиям Contoso, где у вас есть модель Student и Instructor, которые наследуются от модели People с общими свойствами.После переноса это создает единую таблицу People с полем «Дискриминатор».

Является ли эта единственная таблица с Дискриминатором приемлемой, когда требуется нормализация 3NF, или существует подход, в котором я все еще могу уменьшить избыточный код, а также генерировать нормализованныймакет для администраторов БД?

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

Это то, что мне нравится в переполнении стека, обмен идеями и интерпретациями.Итак, вот мое толкование 3NF, и если я ошибаюсь, пожалуйста, поделитесь своими интерпретациями, чтобы я смог выучить. 

public abstract class BaseModel
{
    public int ID { get; set; }
}

public abstract class Person : BaseModel
{
    public string LastName { get; set; }
    public string FirstName { get; set; }
}

public class Student : Person
{
    public DateTime EnrollmentDate { get; set; }
}

public class Instructor : Person
{
    public DateTime HireDate { get; set; }
}

Результатом является одна таблица «Люди» как таковая: ID |Фамилия |FirstName |Дискриминатор |HireDate |EnrollmentDate

Дискриминатор - это NVARCHAR (MAX) или, другими словами, строка, которая будет либо «Инструктором», либо «Студентом»

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

Также существуют транзитивные зависимости, потому что Student определяет EnrollmentDate, но не имеет ничего общего с HireDate, и наоборот для Инструктора.Так что ни один столбец даты не входит в эту таблицу, и я считаю, что эта таблица даже не соответствует требованиям 2NF.

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

-People- ID |Фамилия |Имя

-Students- PersonID |EnrollmentDate

-Instructors- PersonID |HireDate

ИЛИ

-Students- ID |Фамилия |FirstName |EnrollementDate

-Instructors- ID |Фамилия |FirstName |HireDate

Итак, вернемся к исходному сообщению и вопросу: «главная» таблица со столбцом дискриминатора, подходит для нормализации или нет, потому что целью должны быть правильно структурированные таблицы для администраторов БД и в то же время удалениеизбыточные свойства для программиста, для которых нужно беспокоиться о написании форматов, проверок и сообщений об ошибках.С этим вторым моментом, пожалуйста, поделитесь другими решениями, например, если проверки данных могут быть сделаны в DTO или ViewModels вместо этого.

1 Ответ

0 голосов
/ 12 декабря 2018

Исправление было удалено в одну строку

Модели: 

public abstract class BaseModel
{
    public int ID { get; set; }
}
public abstract class BasePerson
{
    public string LastName { get; set; }
    public string FirstName { get; set; }
}
public class Student
{
    public DateTime EnrollmentDate
}
public class Instructor
{
    public DateTime HireDate
}

DbContext: 

public class SchoolContext : DbContext
{
    public SchoolContext(DbContextOptions<SchoolContext> options)
        : base(options)
    {
    }
    public DbSet<Student> Students { get; set; }
    public DbSet<Instructor> Instructors { get; set; }
    // public DbSet<BasePerson> People { get; set; }
}

Если вы включите People DbSet, как показано в учебниках Contoso,когда вы выполняете миграцию и обновление базы данных, вы получаете одну таблицу People в вашей базе данных со столбцом с именем Discriminator после всех унаследованных полей, которые будут иметь значение Student или Instructor и любые уникальные поля в конце таблицы.

Мне пришло в голову, что в BaseModel нет ни одной таблицы Model, потому что в DbContext нет моделей DbSet .Поэтому я попробовал это, и это сработало, удалите строку для DbSet People, и вы получите отдельные таблицы для студентов и преподавателей со всеми унаследованными полями.

...