Natural impedance of objects and databases

Banqiao people http://www.jdon.com (reprinted please)

 

In the article "Comparison of Two analysis and design methods for Object-Oriented Modeling and database modeling", we compared the differences between the two methods for requirement analysis, A database model, such as the data table structure and fields, is created based on the needs of the project at the very beginning. This error phenomenon is widespread in our domestic project practice. It can be seen from the many recruitment revelations each year: recruitment of database modeling personnel and recruitment of Java object-orientedProgramMember. These instructions indicate that the software industry is using a large number of OO languages such as Java/. Net/Ruby on Rails, and at the same time using analysis and design methods that conflict with the OO system around relational databases.

In order to further illustrate that OO and relational databases belong to two different world views, there are natural contradictions, just like thetheistic and theistic, just like water and fire are two completely opposite programming knowledge. Just recently, theserverside published a big talk about odbms'sArticle: When to use an embedded odbms (hereinafter referred to as odbms)
Http://www.theserverside.com/tt/articles/article.tss? L = embeddedodbms

This article not only talks about the natural Impedance Between Oo and relational databases, but also the differences between odbms and RDBMS, as well as the differences between odbms and O/R ing such as hibernate, I even talked about the advantages of odbms in non-C/S, such as embedded systems. The most important value of this article is that it has explained the natural conflicts between objects and relational databases in a large amount of space. I will repost this article here to the general idea, it can be said that after I chew the feedback, the idea of copyright still belongs to this Article. Here I just want to express this natural contradiction in a more acceptable way for Chinese people:

Cumbersome conversion of objects and relational databases

In an object-oriented system, data exists in objects, and in relational databases, data exists in records of data tables.
In the relational database world, we must master table structures, table records, and other concepts. There is no object concept here. When we use relational databases in the OO language, since there are a large number of objects in the OO world, data must be converted and transmitted between the two different worlds.

This results in a large number of temporary junk objects and increases the complexity of the application system. This is why many of us use such oo systems as Java, but feel that the development efficiency is not as high as that of OO propaganda. To put it bluntly, the OO idea does not fully occupy the application system, because the relational database occupies the final bastion of the database, it is stubborn.

Next, let's take a look at how our program binds the OO language and relational database to work together, how to make up for the cracks in both worlds, and how to merge between them. To save objects to a relational database, we must disband the data in the objects, assemble them into SQL, and then execute SQL.
A class is as follows:

Public class course { Public string name; Public int courseid; Int deptid; Public int credithours; }

The SQL statement for saving the preceding object to a relational database is as follows:

Preparedstatement insertstatement = connection. preparestatement ( "Insert into courses (name, courseid, deptid, credithourse)" + "Values (?, ?, ?, ?) "); Insertstatement. setstring (1, course. Name ); Insertstatement. setint (2, course. courseid ); Insertstatement. setint (3, course. deprtid ); Insertstatement. setint (4, course. credithours ); Insertstatement.exe cuteupdate ();

The translation and complexity of the above two worlds depend on the complexity of the object course. If there are more than a dozen course fields, saving the SQL statement will be more complicated.

More importantly, a field changes a lot. We should not only modify objects, but also modify the data table structure. Those who have experience in Database Programming know that if there is data in the table, the problem caused by table structure changes may be like a nightmare, our programmers often reject maintenance and expansion of some software based on this need to change the table structure, which is even more an error. In the odbms article, the object database solution is proposed: as long as the class structure is changed, everything else can be done with odbms; Using ORM, such as Hibernate, has only one more step: Change the ing configuration.

Implementation of inheritance relationships

The mismatch between objects and relational databases is also manifested in the difficulty of implementing inheritance relationships in the object world in relational databases, such:

This is a typical class map of the object world to express the objective world. students and professors are both human beings and have some common characteristics. Of course, there are also differences between them, therefore, we use the above inheritance relationship to express this situation.

How can a class diagram that inherits a link be saved to a relational database? There are two methods: One-Class-per-table (one class corresponds to one table) and one-object-per-row (one object corresponds to one table row ).

In the one-class-per-Table mode, the student object is placed in the student table, and the sequence sor is placed in the sequence sor table. However, student and reduce sor actually share the common person, which divides the data in the Common Object "person" into two tables and saves them. In terms of semantics, student and reduce an object into two parts; and when you want to obtain this object, you need to select the object twice. In the same way, it takes two times to add, delete, modify, and query data.

If you use one-object-per-row, place the student and cursor sor in a table, a blank field is generated. If the data in the student object is saved to the field corresponding to the student object, the field corresponding to the else sor object is empty, and vice versa.

These all reflect the natural mismatch between objects and relational databases, and they cannot work together at all. Only one party can make a compromise. In most cases, the object can make a compromise, an OO language Java /. NET system is built into a database center system, and it cannot enjoy the fast, convenient and maintainability brought by the OO language. Due to the early appearance of Java, more programmers attribute the project failure to the Java language, instead, we use database thinking. net, when we do Ruby on Rails, we will still encounter these problems. If we do not encounter them, we can only show that they do not have the object concept in their systems. The solution is very simple and ridiculous: conflicts between the two sides, the elimination of one party soon resolved the conflict.

Implementation of complex relationships of Classes

Next, let's take a look at how to save the complex class relationships listed in odbms Using relational databases:

Public class Department { Private esssor [] professors; ...}

This department class clearly tells us this meaning. In a department, there are many Professor workers. In the vernacular, there are many professors in a department. This class naturally and accurately expresses this meaning, this also reflects the nature and convenience of using OO to express the demand.

Next let's take a look. If we use a relational database to save the Department object, it is clear that we need to use the foreign table key of the relational database, the table foreign key is used to express the 1: n relationship between the department table and the partition sor. The key problem is that the foreign key is generally designed in the partition sor table, which leads to semantic misunderstanding.

The requirement of object department is as follows:
1. I am a department object and contain many professors.

When this object is in a relational database, because the foreign key is in the analyzer table, it means:
2. I am a professor. Here is a department object.

The comparison between the two shows that the two expressions are completely different. This is already a copy. When we get the department object from the relational database, you have to follow the Relational Database Rules to get a complete department object. That is to say: every time we get an object department, we have to translate the meaning of this requirement into a relational database expression. This kind of consumable translation is not only prone to errors, but also brings the burden on programmers to develop. In case of translation errors, the problem is serious.

Of course, if we use odbms, we do not have to do these laborious translation transformations, nor do we go around the curve, as long as we directly tell the odbms or ORM framework such as Hibernate, to get a department in the true object sense.

The above section describes the conflict between objects and relational databases in a large part of TSS odbms. Therefore, we think that if you use an object language, such as Java /. net/Ruby on Rails, etc. Therefore, we must adhere to OO ideas and methods to prevent the impact of relational databases on software from the program, the relational database is regarded as the "hibernate" of the active object, which is the meaning of the ORM framework hibernate.