Use of Generalization / Specialization in data modeling

I do not really like this idea. To tell the truth, it is more absurd and if applied creates very strange things. At least in the database if you generalize the right way is not to have any difficulty.

In a statement there are some who say, and today have to agree in most cases, that a data type must be prepared to be specialized and not allow to create a concrete object of it, or be able to create the concrete object and can not be specialized. There are useful exceptions to this, so a type is allowed to generate a concrete object and be specialized, but should not be abused.

In the database you do not have this need, or it is general and will never have data of this type or it is specific and has data, never both. So the generalized type is only part of the logical model to better organize the model, there will be no data persistent in the storage with this type, it will only have the specific types, so doing so is right its problem does not exist , there is only real primary key in the specialized type.

If you insist on doing wrong, I do not even think you're doing specialization, you're normalizing tables by establishing a relationship. And with worse performance for zero gain. If it's really a specialization the relationship is 1: 1 , completely unnecessary in almost every case where it's doing right. It does not make sense.

There is no such thing as specializing some entities and generalizing others, there is the establishment of generality and specialty relationship between entities. When you realize that there is a pattern in certain entities and this can cause the creation of the idea of a general logical entity so that every time you move it has to move together in their specialized, you must do. There are fewer such cases than they might seem. Most of the cases that people think have this kind of relationship in fact from other forms of data composition are usually papers.

The cited link examples are bad and apparently done because who does not make real software. Individuals and legal entities are not specializations of a client in any context. In general you have the physical or legal person who are concrete (and may have person with abstract generalization) and the client is only a role of a person. The example even is too simplistic to teach something useful. More or less the same goes for others.

To do everything right you need to understand a lot of the subject you are modeling, you have to practice a lot of taxonomy and ontology. It is necessary to understand the relationships of things outside the software to model right inside it. If you do not understand what each understood and the real relationship between them you will model wrong or hit only by coincidence, a real lottery. There is no book, course or anything that teaches this. The only way is to build knowledge by consuming, observing, debating, practicing on these domains and general subjects, to form logical, critical, and holistic thinking about the world and systems already established in the real world.

Some related questions:

• Can it be considered a bad modeling practice to store all people (customers, employees, suppliers) in a single table?
• Employee Can Be Individual Role?
• How to represent "is-one" relationships in the logical model?
• Inheritance and Polymorphism
• What to do if client can be both PF and PJ?