Entities classes

Asked

Viewed 114 times

3

I am developing a sales project to which I will have registered a funcionário which may also be a vendedor, I’m gonna have a cliente which may be a pessoa física or pessoa jurídica, fornecedores that may be pessoa jurídica. The rule is I’m gonna have one proposta to which it will be linked to a cliente.

At the end I’ll have a venda which will require a cliente, one vendedor and a proposta.

I created an entity pessoa which could be used as cliente, fornecedor and funcionário. But as far as the client is concerned, I wonder, is it really necessary to have an entity cliente? When I added it was thinking that a venda can’t have a pessoa, because a pessoa can be fornecedor and funcionário and not a cliente if the entity does not exist.

DER

  • Did the answer solve your question? Do you think you can accept it? See [tour] if you don’t know how you do it. This would help a lot to indicate that the solution was useful to you. You can also vote on any question or answer you find useful on the entire site

1 answer

5

You’re going the right way. I wonder if I should have Pessoa. This is abstractly cool, but physically I do not think should have, almost always this is a mistake and in database will only lose performance. Sure, you can do it like this, because conceptually there’s nothing wrong, I just don’t think it’s a good idea.

I do not know this notation but has 3 forms of relationship and do not understand what means two of them, do not seem to be relationships.

I can’t say if you need the Cliente or not, if it’s just to have a id you don’t have to, but that goes for Funcionario and Vendedor too. And I don’t know if I would Vendedor to Funcionario, one day may have a Vendedor that does not work there, or even that is a legal person. It is better to unlink it.

  • True, I may have one salesman who is representative. The client is just for me to physically identify in the bank a client among several people, people who may be suppliers or employees. I thought about removing this client entity, but I see no other way to relate my proposals to a person.

  • If that’s all I don’t see how I couldn’t link directly. It’s just that it’s almost certain that you’ll have other customer-specific things.

  • Two questions: 1) If Seller is an Employee role, why 1 employee for n sellers? Shouldn’t it be 1 to 1? Same thing for Person and Customer (1 person for n customers). 2) Why in the bank Person will lose performance?

  • 1

    I think Vendedor is a role, not necessarily of Funcionario, but it is right that under normal conditions it would be 1:1. There may be some situation that is not, but quite strange. Having Pessoa also, are two tables to consult, the general and the most specific, almost zero organization gain, and which in practice is very rare need alone. You might even say you have Cliente, Fornecedor, etc. is worth the same. But this is a case that organizes much more, because it is a paper,in many cases you will not need to take 2 tables (the paper and the entity) and can have several roles at the same time,Pessoa only 1

  • From what I saw Employee Spreads Personal Physicals. Would it be wrong to model it instead as Personal Physicals role? Only then Seller would be paper role :)

  • 1

    @Piovezan I think yes, this is a case that does not fit a role. But to say that you should never do this I do not say.

  • @Maniero Just so I understand better, why in this case does not fit the role?

  • Because it’s not a role, in my view, one could argue, I can have a vision that is yes. After all Pessoa is a person, and be Física or Jurídica It is only one condition of it. But I prefer to see that pu person is physical or legal, it can’t be both. When it is excluding it makes no sense to have papers. There fits a é um, and not a tem um. That’s why I don’t like these relationship names of this ERI, but I don’t question them. Being generates inheritance, having generates composition.

Show 3 more comments

Browser other questions tagged

You are not signed in. Login or sign up in order to post.