Implementing the concept of inheritance in a database

Question

Why the attribute PessoaJuridicaId is not generated?

This is the base class Pessoa:

public class Pessoa
{
    public Pessoa()
    {
        DataCadastro = DateTime.Now;
    }
    public int PessoaId { get; set; }
    public DateTime DataCadastro { get; set; }
    public string Observacao { get; set; }
    public bool Ativo { get; set; }
}

This is the class PessoaJuridica who inherits from the class Pessoa:

public class PessoaJuridica: Pessoa
{
    public int PessoaJuridicaId { get; set; }
    public string RazaoSocial { get; set; }
    public string NomeComercial { get; set; }
    public string CNPJ { get; set; }
    public string IE { get; set; }
    public string IM { get; set; }
    public string CCM { get; set; }
    public DateTime? DataAbertura { get; set; }
}

This is the Repository class:

public void Salvar(PessoaJuridica pessoaJuridica)
{
    _repositorio.PessoaJuridica.Add(pessoaJuridica);
    _repositorio.SaveChanges();
}

Answer 1

I was just going to comment, but it got long and I think that deep down the error is conceptual.

Where is it written that it should be auto-incremented? What is the criterion for generating an auto-incremented identifier? This will not occur alone. Alone the Entity Framework can only do with the first field, in case it did with PessoaID which is the first already inherited. In fact he did right, if he wants to inherit it.

I find it strange to have different identifiers in both tables and to have an inheritance relationship. This only occurs when there is some kind of composition, association or aggregation, not of inheritance. If inheritance is then legal entity is the same as person, they do not exist separately, why should they have different identifiers? I think the EF did right, your model that is adding something unnecessary: PessoaJuridicaId.

In general I prefer to make, at most, a logical inheritance, but concretely to have only the tables of the subtypes with the replicated data, which is what happens concretely in memory when we use inheritance in a language, the object is unique, there are not two of the base class and the derivative.

To tell the truth, this model of having a physical base table and its separate derivatives generates a composition and not a de facto inheritance. Inheritance is a logical thing to reuse code, not to reuse data. In general having this composition of tables does not bring any benefit and even brings harm, so there is no reason to use. Of course you can have some case that might be worth it. But you need to conceptualize it right, understand all the implications. You can’t just do it, do it because "it worked," you have to do it right.

I’m not a big fan of database inheritance because almost everyone does it wrong. I don’t even know if I know how to do it right, but I know most people do it wrong :) Object orientation is already too complicated in memory and people think it’s not, in even more databases. You know the story that drowns the person who thinks he can swim. Those who can’t swim don’t die because they don’t try. Who knows how to swim doesn’t die because he knows. The problem is when You think you can swim and you don’t know.

You have some questions on the subject:

• Inheritance in the Entityframework
• Inheritance in the Entity Framework
• Inheritance X Composition - Mysql C# Entity
• RU with TPT inheritance and audit fields
• How to configure Entity Framework Mapping 1:N using inheritance
• EF 6, Fluent Api mapping in inheritance classes
• Inheritance with Repository Pattern