MyBatis know how (11) Enterprise database

Enterprise databases are larger than application databases and have greater external impact. There are more relationships between them and other systems, including dependencies and dependency relationships. These relationships may be between a Web application and a reporting tool, but it is also likely to be an interface with other complex systems and databases. In an enterprise database, there is more than just an external interface that is far more than the application database, and these interfaces are very different in how they work. Some interfaces may be interfaces for bulk load of data per night, while others may be real-time transaction interfaces. For these reasons, the enterprise database itself may actually be made up of more than one database. An example of an enterprise database is depicted at a higher level.

The enterprise database imposes many restrictions on its design and use. For data integrity, performance, and security, enterprise databases tend to account for more factors than application databases. For this reason, the enterprise database is split into multiple parts, separating the concerns and separating the requirements. If you attempt to create only a single database to meet all the requirements of an enterprise system, the cost will be expensive and complex, or not practical or even impossible at all.

For example, the requirements are divided according to the horizontal non-business requirements. Specifically, these databases are divided into integrated databases (integration database), online transaction databases (transactional database), and reporting databases (Reporting database). Both the integration database and the reporting database interact with the transactional database through bulk load (batch load), which implies that the system does not require the report to be up-to-date, and that the transactional database only requires the ability to periodically update data from third-party systems. The benefit of this design is that we can greatly reduce the burden on the transactional database, making a simpler design possible. In general, it is impractical to design a database that is both efficient for integration, transactional, and reporting. There are some design patterns for each of these properties to ensure optimal performance and design. But sometimes our needs are similar to real-time integration and reporting capabilities. The design before such a requirement is not satisfied. You may find that you need to divide the enterprise database vertically by business functions.

Regardless of how the enterprise database is designed, it is easy to understand the differences between the application database and the enterprise database. It is important to understand the specific limitations of your environment to ensure that your application can always use the database efficiently and be peaceful with other applications that use the current database.

MyBatis works very well in the enterprise database environment. Its features make it an ideal tool for coordinating work with complex database designs and large datasets. Ibatis is also excellent when used with multiple databases because it never assumes that an object of a type must come from only one database. It also supports complex transactions involving multiple databases in a single transaction. In addition, MyBatis is useful not only for online transaction systems, but also for reporting systems and integrated systems.

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