Vixi, you’re mixing three things in there and it really gets messy. In databases, and even in UML, attribute is the term used, in programming languages such as C# no, the correct term is field, or how it is used in models Entity Framework or MVC, property (which is a slightly different concept).
I am a data migrator and every day, I have the pleasure and displeasure to know numerous databases of the most varied commercial systems in the market. My doubt lies in the way people model the fields of tables
Commercial shelf ERP systems are usually used by various types of companies, each with their own needs, so the development of these software is quite different from what is taught there. I specialize in this kind of software. Each company operates in a different way and has no other way than to allow parameterization of what to do. There’s a way to make it better or worse, and my experience is that everyone makes a bad mistake because:
There are those who exaggerate, there are those who model something as if it were another, there are those who choose the wrong mechanism to give this flexibility.
Why people create General Parameters tables where they create fields in parameter form and store such information?
There are cases that is not even software flexibility, is item flexibility or even a condition that can be considered a parameter. I don’t think PermitirVendasSemEstoque or UtilizaBalanca be a parameter. PermitirAnaliseCredito or PermitirEdicaoDescricao Could be, but it depends on more context to be sure. Where it is makes a lot of difference, being in the table and belonging to each registered item does not seem software parameter.
For example, UtilizaBalanca is something important because there is an item that has a weight controlled by the scale and it has implications in the system, but there is product that does not behave like this, so you have to deal with it, how else would you know whether to control that item in one way or another if you don’t have information that indicates that?
There are good practices to be followed for the modeling of tables in relation to what was mentioned in doubt 1?
No, I always say you should not cling to "good practice". The question is too generic to even cite some items to be observed, and even if it cites it cannot be applied to all cases.
It would be better to play all the fields on a table or make a global table of parameters and play everything in?
It depends on what you want to do, it has no better, it is not a general choice, there is no single situation, it should be as granular as necessary. If it is something that should influence the whole it must be global, if it is something that should work in a certain context it must parameterize to this context, if it is something for a table, for a group of items or a specific item it must be in each of these. This is a model. Contrary to what people believe modeling is not taking a rule and applying, it is understanding the problem and creating a model that solves well everything you need today and that is easy to evolve in the future.
Modeling is the most important aspect of software development, in fact the only one that the person has to be very good. And everyone fails at it, only the ones who fail the least.
How to identify what should go for each table?
Absurdly broad answer this except to say to verify the need, which is a very generic response to serve something. Or I can answer what I said before, put in general table what is general, in specific table what is specific. There is no magic, you have to know what is general or specific in each case.
To do this is necessary:
- good understanding of general logic (not programming)
- text interpretation (and text creation)
- mathematical understanding (not decorating formula)
- a very broad learning ability to deepen knowledge about a domain that you do not yet know well and see what is not always obvious
- and experience to avoid traps, something that can only happen when you’ve fallen into many.
Creating simple Cruds is easy, making software is very difficult because it is not enough to know a programming language and the basics of a database.
Just to try to give an example, consider PermitirAnaliseCredito be something that a company (that uses the software) does or does not do, in general, for all customers. Where will put this? It should be obvious that it is something global. If this decision depends on each individual client it would be obvious that it should be a client table field, right?
I often say that people make mistakes even when they create a table Clientes (there is no such entity in the real world, there is a customer relationship that is conceptually very different and makes all the difference when modeling). I replied about DRY OF INFORMATION, if you have the same entity registered twice, as a customer and as a supplier for example, you do not have a canonical information, then a lot will go wrong from there on.
This example of a parameter
PermitirVendasSemEstoque... You say in relation to "item registration", because in case you could "move" stock or not by a "type of operation", or in any way?– rbz
So I can’t say anything without understanding the problem, but it’s a possibility that it’s this, it might be something else.
– Maniero
And yet, if you need to "force" a "weighing", not having a parameter
UtilizaBalanca, would then be a separate table to "relate" the required items?– rbz
Perhaps, without details I have no way to answer. That’s what I say people think that you can make decisions without details. Note that I ask for details in many questions and does not come, the problem of people is that they do not know how to ask questions, they cannot give the details necessary for the question to be understandable and can be answered properly, then the person gets angry, Even because some people think they can answer without details, she’s naive at this point. Modeling is asking the questions the right way, the answer is only a consequence of the right question.
– Maniero
That’s why I talk about text interpretation when you model.
– Maniero