MyBatis know how much (15) data Model

The thin data model is one of the most notorious and problematic abuses of relational database systems. Unfortunately, there are times when you really need a thin data model. The so-called thin data model is simply to design each table as a common data structure for storing a collection of name-value pairs. This is much like a property file in Java. Sometimes these tables can also be used to store metadata, such as the desired data type. This is necessary because the database only allows one column to have a type definition. To better understand the thin data model, consider the following example of typical address data, as shown in table 1-2.

Table 1-2 address data in a typical model Addressjd STREET City State Zip Country 1 123 Some Street San Francisco California 12345 USA 2 456 another Street New York New York 54321 USA

It is clear that this address data table can be further regulated by the I paradigm. For example, you can create an association table such as Country (country), state, city, and zip (Zip). But the current design is simple and efficient enough for most applications. Unless your needs are really complex, this model should have no problem.

	If you put them in a table corresponding to a thin data model,	The results are shown in table 1-3.
	Table 1-3 Thin Data module Address data in type
AD DRESSJD	FIELD	VALUE
1	STREET	123 Some Street
	City	San Francisco

Continued
ADDRESS ID	FIELD	VALUE
1	State	California
1	Zip	12345
1	Country	USA
2	STREET	456 another Street
2	State	New York
2	Zip	54321
2	Country	USA

Such a design is definitely a nightmare. First, there is no possibility to further normalize it, although the current model can only be counted as the first paradigm. Second, there is no opportunity to create an association with the country table, the city table, the state table, or the zip table, because it is not possible to define multiple foreign keys on the same column. Again, if you want to execute a "sample query" that involves multiple address fields (for example, a query statement that takes streets and cities as query criteria), such data can be a headache, and it may require a whole bunch of complex subqueries. Looking at the update, this design is particularly bad for performance, just inserting an address requires executing 5 INSERT statements on the same table. In this case, the possibility of lock competition or even deadlock is greatly increased. In addition, the number of records in this thin data model is 5 times times that of our normalized data model. Creating a valid index is not possible because the number of records is too large, there is a lack of explicit data definitions, and too many update statements are required to update a record.

Needless to say, this design is indeed a lot of problems, why we should at all costs to avoid such a design, the reason has been understood. But then again, the design is not useless, and its only use is in applications that require dynamic fields. Some applications do have this requirement, which allows users to add additional data to their records. This model works well if the user wants to be able to define new fields and then dynamically insert data into those fields when the application is run. That is, all known data should be normalized correctly, and these additional dynamic fields can establish a parent-child relationship with these known data through an association relationship. This design also has all the problems we discussed earlier, but they are minimized because most of the data (most likely the most important data) has been properly normalized.

Even if you encounter a thin data model in an enterprise database, MyBatis can help you handle it. It is difficult or even impossible to map several classes into a thin data model, because you cannot even define which fields are possible in the data model. At this point you'd better map such a class to a hash table (hashtable), and fortunately Ibatis supports this mapping. With MyBatis, you don't have to map each table to a user-defined class. MyBatis allows you to map relational data to Java Basic types (primitive), map instances, XML, and user-defined classes (such as JavaBean). This great flexibility makes the ibatis very effective for complex data models, including thin data models.

MyBatis is designed as a hybrid solution that does not attempt to solve all of the problems, but rather it only wants to solve the most important problems. MyBatis has drawn a lot of good ideas from various database access tools. Like stored procedures, all mybatis statements have a signature that defines the name of the statement and the input and output (encapsulation). Like inline SQL, MyBatis allows SQL statements to be written in the most natural way, and can be used directly from variables in the language as input and output parameters and results. Like the dynamic sql-sample, MyBatis allows SQL to be modified at run time. Such query statements can be built dynamically based on the user's request. From the object/relational mapping tool, MyBatis borrowed a number of concepts, including caching, lazy loading, and more advanced transaction management.

In the architecture of an application, the mybatis applies to the persistence layer. MyBatis also provides features to support other tiers, which make it easier to implement all of these layers. For example, a web search engine might need a paged list of search results. MyBatis supports this feature because it allows the polling to specify the offset and number of rows to return the result. This allows paging operations to be performed at a lower level, while keeping the database details away from our application.

MyBatis can be used for any size and purpose database. First of all, MyBatis is well suited for smaller application databases because it is very easy to learn and get started quickly. Second, MyBatis is also very suitable for large enterprise applications because it does not make any assumptions about the design, behavior, or dependencies of the database that might affect how our application uses the database. Again, MyBatis can work well even for databases that are controversial in design or mired in high-level policy chaos. To sum up, MyBatis is designed to be very flexible enough to fit almost any situation. Of course, using MyBatis can also save you a lot of time, because you don't have to write duplicate, sample-like code anymore.

The concept and origin of MyBatis are discussed. The following will carefully explain what mybatis is and how it works.

Series Articles:

MyBatis know how much (1)

MyBatis know how much (2)

MyBatis know how much (3)

MyBatis know how (4) The advantages of MyBatis

MyBatis know how much (5) Business object model

MyBatis know how (6) presentation layer and business logic layer

MyBatis know how much (7) persistence layer

MyBatis know how (8) relational database

MyBatis know how (9) different types of databases

MyBatis know how (10) application database

MyBatis know how (11) Enterprise database

MyBatis know how much (12) Private Database

MyBatis know how much (MyBatis) How to solve common problems in database

MyBatis know how (14) Decentralized database system

MyBatis know how much (15) data Model