5
In a flow that allows the registration of natural persons and legal persons I have seen the two approaches, but I’m not sure whether it is a good practice to store the two information in a column cpf_cnpj and then have a field of flag to inform the field type, or even use the amount of characters in the field seems to me a bit forced.
How I am using ORM (Entity Framework) could be best practice to have a derivation of the type User for PersonalUser and BusinessUser?
6
Search right here on the site what I and other people think about "good practices".
Good practice is to do what is right for what you need. And only you with your concrete case can say what is right for that case.
I always separate individuals from legal entities, because clearly they are very different entities. But it works keep together, I think it takes more work and complicates some things. My experience is that even though it takes a little work to separate is more conceptually correct and ends up simplifying some things. If you know how to abstract it is not so difficult to deal with both.
And that last point is important because it doesn’t do you any good to make a right decision and all the others that come next, even as a result, are wrong. And that’s just another reason for adopting good practice can be bad practice, the person thinks it’s enough and everything will be great.
It’s like people adopting the "good practice" of microservices because it scales more easily. She just doesn’t know that she’s embracing the hardest computing problem in her architecture and that she’ll probably do it all wrong and it’ll be much worse.
Then we get into that thing, "the best tool is the one you know," or put another way:
The best practice is the one you can do right
I just think it’s weird that a user can be legal. I don’t remember seeing that anywhere. I saw relationship entities being companies, but not users. It seems, but I can’t say that there is a confusion of concepts there. Again, you are the one who knows your requirements.
What I do not do is separate activities from these entities as customers, suppliers, etc.
I’ve already given some answers on that:
0
I don’t really like the idea of putting everything together and using flags or string sizes to differentiate PF from PJ. Tomorrow the government can create a third (NGO type) that is neither physical nor legal. And there your flag becomes meaningless. Define by size also not a good, because the numbers can grow. I’ve seen places that book 15 digits for PJ, 12 for PF, 9 for landlines... and so on...
I prefer the approach I saw in a company I worked at: A table for people containing data common to both types, a table for PF and a table for PJ. The PJ table stored only the CNPJ base and there was another table that stored the branches, the part that comes after the '/'. Because one thing many do not remember is the branches of a CNPJ.
Confused right? But to make it easier, a view was created that brought together everything, PF, PJ and its branches.
Some twist their tail for views, for performance reasons, etc. So what? The machines are getting faster and faster, I see no concern for that.
There is already a third party which is the legal alien with different rules in each country. It is not necessary in all types of register but there is this, in general for foreign trade. And there may be other specificities, so it tends to be a good strategy to separate, but I don’t think that’s the biggest reason, even though it’s valid as well. And the problem is not even the type is all the rest that can change. Actually the size can be problematic, but it can be solved. The solution of having a table for person and others for PF and PJ is conceptually correct, but is not performative, can go well...
... in some scenarios, but one day the situation changes and it becomes a problem. I don’t think a branch chart is a good idea, but I might not know something you know. It is possible in the same table to differentiate this more appropriately. The idea of view well implemented can be useful in some scenarios, but can be an indicator of problem. I was gonna say yes, but the fact that you say performance doesn’t matter is a mistake.
If the machines are so fast that this is no longer a problem people no longer turn to microservices because they have made the software so slow that no machine can handle more even in volumes not so big. That’s why it has a small site or something internal that needs microservice and this site that is one of the 30 most accessed in Brazil does not need and could run on a machine. Otherwise the answer is good, by offering alternatives that makes some sense.
Don’t take this the wrong way. Some people think that views have bad performance, but that doesn’t mean that they really have bad performance. This solution runs in one of the largest insurers in the country (where I work currently) and I see nothing bad performance. On the contrary, it is fully scalable by the database.
About Microservices, its adoption is due to the fact that it solves very well problems of scalability, resilience, maintenance, etc. Of course it affects performance because everything revolves in terms of network connections, but it is preferable to have a part of the domain not working rather than te-lo whole dropped because a simple query does not work. To solve the performance, there are several techniques such as CQRS, Event-driven, etc. Just have a good design and no one needs to maintain extremely performative monolithics to the point of being able to run on one machine.
0
At first I understand good practice yes have in the same column the registration of Cpf and cnpj in the same field. you would create a unique register of persons (both legal and physical) avoiding situations of duplication of these registrations. It is also correct to use a field (flag) that defines the type of person, which could also be dispensable, if we consider that Cpf has 11 digits and cnpj has 14. In programming you can differentiate that by the length of the variable that brings that information.
An example of how useful this practice would be: Suppose a company will make a purchase in your establishment. It is relevant that in such a situation the registration of the legal person relates to a natural person as a legal representative.
Now suppose that this natural person already registered as a legal representative wishes to make a private purchase, with no link to the legal person he represents. in this case you will already have the registration of this person without having to duplicate the information.
If there is doubt in how to proceed this binding of the legal representative to the company, the suggestion is to create a table for this link (n for n). Thus, depending on the case or need, it will be possible to include several legal representatives (natural persons) for each company (legal entity), as well as it will be possible to inform the same natural person as legal representative of several companies.
In addition to avoid duplications of registrations in these cases, when situations occur that it is necessary to update a person’s registration, it will not be necessary to keep looking if he is legal representative of companies to update in these cases also.
In general I always recommend and apply this practice, but as Maniero well said, each case should be analyzed and done as really necessary and more efficient.
Browser other questions tagged database entity-framework modeling software-architecture
You are not signed in. Login or sign up in order to post.
Thank you very much for your prompt reply. In reality as it is a fintech application, we will have the possibility a PF user can register in order to carry out banking operations, and in the same way in the future the idea is to contemplate account support for companies and legal entities. I am trying to structure a backend for this application. I will read your answers for sure.
– adamasan
Having PF and PJ account is different from having user, including it is common for a company to want to have multiple users, so I said that I think the concept may be wrong.
– Maniero
Yes, I will still give one more analyzed with the business part to understand the issue more in depth. Thanks for the heads up.
– adamasan