Database Design in Object-Oriented Methods

(I saw an article about the relationship between object-oriented design and database design. I think it is very good. I will post it again .)

There is no data stream in object-oriented systems. The business is completed by objects and messages. There is only "Object stream" and no data stream.

In reality, the persistence of most objects is implemented by relational databases. We have not replaced the object databases of relational databases in terms of performance and query. The purpose of designing a database table is not to consider the so-called "stream", but to consider how to make objects highly efficient and persistent. It can be said that the database design and the previous object-oriented design are two issues in the field. The object-oriented design solves the problem of business execution logic, the Database Design solves the problem of data efficiency (it does not consider the concept of flow control at all), and they are combined through the or-mapping mechanism. If you have doubts about this, it means that you are trying to consider expressing business logic through database table design when designing database tables, rather than considering how to efficiently persist objects.

Assuming that the current technology is mature and we already have an XML persistence mechanism and an object query mechanism with a performance not lower than that of relational databases. Any object can be directly persisted without or-mapping, do I still need to design database tables?

I want to talk about some ideas about object-oriented database design. I want to answer this question and talk more about how to design a database in the object-oriented method.

The first thing I want to talk about is that the process-oriented data stream analysis method is not correct, but it does not conform to the object analysis method. The starting points of the two are different. Just like teams heading in two different directions, they cannot be combined. The so-called object-oriented design, "first creating a database table, then encapsulating it, and designing a class" is a complete error! Put on an object-oriented vest, which is not object-oriented at all. The table design under the process-oriented method also involves data stream derivation. This pseudo-object method discards the data stream vest to put on the object-oriented scheme, but does not follow the object analysis method, we don't even know how database tables are derived.

Hibernate, which is the most widely used, has many misuse in practice. Or-mapping is regarded only as a simple one-to-one correspondence between physical tables and objects in the database. In essence, it is necessary to design databases before designing classes. Once again, we emphasize that "object-oriented design solves the problem of business execution logic, and database design solves the problem of data efficiency". They are essentially two areas of design and are only connected by or-mapping. To use the object-oriented method, first forget the existence of the database and use the object analysis method. First, analyze and define the object to ensure that the business execution logic can be well completed by these objects. After this is achieved, the problem of Object persistence will be considered. Objects are persisted based on the three major database paradigms and performance requirements. Note !! At this time, the problem we need to solve when designing a database is "efficient and Persistent Object Data", rather than business logic! It is not derived from the requirement!
For example, in process-oriented design, an application form may be designed into a physical table. In object-oriented design, there may be no physical table like the application form, however, there are only "User Data", "application process", "application qualification" and other object tables. The so-called application objects are aggregated by these objects at runtime.

Each object has its own attributes and States. We need to save the attributes and states of this object in the database. The most ideal and simplest case is that an object corresponds to a physical table, the relationships between objects (one-to-one, one-to-many, and many-to-many) can also be simply mapped to the primary-foreign key relationship of the database. However, there are many non-database relationships to consider, such as inheritance, aggregation, and dependency. How does one table inherit from another table? The relational database obviously does not have such a definition, so we need to use or-mapping to complete this semantic conversion. For example, when a child object is instantiated, or-mapping reads the attributes of the parent object from the table representing the "parent" object and assigns it to the child object. When the parent object changes, or-mapping needs to reflect this change to all sub-object instances (this is only an OR-mapping solution, and also implements redundant storage of parent object attributes in all sub-tables ). Another example is to aggregate an object. A company object consists of the company's basic information and a department list. When this object is persisted, it must be clearly divided into the company table and department table (one-to-multiple relationship ), when operating company objects during business logic execution, they are always one object, however, when cudr is an object, or-mapping is responsible for converting operations on the object to operations on the two tables. Dependency indicates the dependency between two objects. When one object changes, the other object changes accordingly. This can be performed by insert/update/delete in the database.
But it is better to manage the relationship by or-mapping.

In fact, the situation we encounter is only more complex. A complex business object may correspond to many tables in the database. Some simple objects may only correspond to a part of a table in the database. Now we should understand the role of or-mapping. It is not as simple as translating a data table directly into an object. It is responsible for converting the object link semantics into the data link semantics. In other words, or-mapping is responsible for the separation of "data" and "performance". How to store and query data is one thing (determined by the three major paradigms and performance optimization considerations ), how data is presented is another matter (determined by the business execution logic and efficient object-oriented design ). If an OR-Mapping Job is well enough to perfectly support conversion between object and data relationships, you can independently change objects and databases, then, you only need to reconfigure the mapping relationship.

A typical example is that in object-oriented design, business logic and control logic are usually separated. For example, for an order object, in terms of business execution logic, in addition to business data, it also needs some state attributes to identify the process control process. However, process control processes are generally not part of the business data, it is only the control logic of the system. In a good object-oriented design, this control logic can be separated and identified by another set of objects. Then, the two can be dynamically bound through object aggregation or dependency injection between objects. In the database design based on data flow, the usual practice is to design the state control field and the business field in the same table. The result is that the control logic is statically bound to the business logic, which means that neither of them can be changed independently. You only need to check whether the business table needs to be changed when the process changes in many systems or the process needs to be changed when the business data changes. This shows that the design is not an object-oriented design, or at least a poor object-oriented design. The really good object-oriented design separates the business logic and control logic. During the running process, the Business Object and the process control object are independently loaded and dynamically bound under the process control framework. This means that both of them have the capability of independent changes. Under this foundation, the results of persistence Business Objects and process control objects will inevitably form a set of process control tables and a group of business data tables. There is no static dependency between them, the control status of a process instance only exists in the process control table rather than in the business table. Therefore, process control and business can be decoupled and independently changed.

If we make the revolution more thorough, we can even regard the database as a means to store data, rather than giving up database constraints, such as the primary-foreign key relationship. I tried this in a previous project. All database tables have no primary-foreign key relationship, no trigger, no constraint, and each table is independent, each table is the result of direct object persistence, and the database does not even manage the association between objects. Each table is identified by only one unique primary key ID. The relationships between objects are all abstracted and managed using a group of object relationship tables. A relational table record represents a relationship between two object IDs, managed by an object relationship management framework. The object Relationship Management Framework manages simple relationships such as "association", "inheritance", and "dependency" between objects. After extension, these relationships can be extended into more complex object relationships, for example, you can add a time factor to a link to indicate that two objects are "associated" or "inherited" within a certain period of time, and also add a version factor, it indicates that two objects are "associated" in a specific version. You can even add a condition factor to use a regular expression to express the conditions under which the two objects are "associated. In this management framework, objects theoretically have unlimited scalability, but this capability does not depend on databases. Changes to a database table only affect the objects that are persistent. We can dynamically create object associations in the Program (add a relational instance to the Relationship Management Framework) to dynamically create a brand new object, we can also extend the relationships in the relationship management framework to get more complex object combinations.

However, the complete revolution is not perfect. This thorough break from the database means that we have abandoned the database's efficiency at the same time, object Relationships managed by programs are not only a complex framework, but also the overall performance is greatly affected! For example, when an object with sub-objects adopts database relationship management, we can use an SQL statement to load this object. After using the object relationship management framework, we must first obtain an object, then, ask the relationship management framework about the Object ID associated with it, and then load it. This process will inevitably produce multiple SQL calls. All curd operations require additional consulting and operations on the Relationship Management Framework, resulting in scalability while compromising performance. However, the reality is that, in the worst of life, some will always be lost. Fortunately, this framework is quite effective in scenarios with low performance requirements! So that we have never had a headache with database modification during the project process, because our program logic, display logic, and so on are not coupled with the database, we use a type called valueobject
Pojo is used as the business entity object and Display object, and this valueobject is dynamically combined by the Relationship Management framework based on the object relationship (persistence object. It is equivalent to decoupling the persistence results of object objects and object objects. Naturally, database modification becomes much easier.

Today's article discusses in detail the database design methods in object-oriented methods. If you are an object-oriented revolutionary or angry, you can claim that object-oriented design does not need a database (it is estimated that this is a minority )! If you are a process-oriented conservative, you can claim that database design is the core of everything (probably the majority )! However, we are still realistic. From the perspective of pragmatism, we acknowledge that:

1. The object-oriented method is very effective. The database design should focus on the efficient persistence of objects rather than the database design;
2. The efficiency and convenience of relational databases are not easily achieved by the object database model in a short period of time. We cannot scatter the baby because of dirty water;
3. The best way is to sacrifice the object-oriented features to meet the performance requirements based on the performance and scalability requirements of actual projects, in scenarios with high scalability requirements, you can sacrifice the database performance to meet scalability requirements.

Source