Description: This article is a guidebook for beginners in the principles of Oracle database application design.
Tags: database architecture, architecture design, Oracle optimization, architect
Purpose: to help you design a more efficient and reliable database application architecture.
Easy to learn: no need is deleted from the text. ?????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? The superfluous part of, let beginners
know it at a glance, and then learn it. Warm reminder: If you find a problem or a better way of writing this article, please leave a message or private message me to modify and optimize
★ Related documents
※ Oracle official documents (21c)
Application design principles
Simple application design
The application is no different from any other designed and manufactured product. Well-designed structures, computers and tools are generally reliable, easy to use and maintain, and simple in concept. In the most general terms, if the design looks correct, it may be correct. This principle should always be kept in mind when building applications.
Please consider the following design issues:
-
If the form design is so complicated that no one can fully understand it, then the form design may be terrible.
-
If the SQL statement is too long and involves too many, so that any optimizer can not effectively optimize it in real time, there may be wrong statements, basic transactions or table design.
-
If there is an index on the table, and the same column is indexed repeatedly, it may be a poor index design.
-
If the query submitted does not have the proper qualifications for online users to respond quickly, it may be due to poor user interface or transaction design.
-
If the call to the database is abstracted from the application logic through multi-layer software, it may be a bad software development method.
Data modeling
Data modeling is important for successful relational application design. You must perform this modeling in a way that quickly represents business practices. The correct data model may cause heated debate. It is important to apply the largest modeling effort to those entities that are affected by the most frequent business transactions. In the modeling phase, people are very willing to spend too much time modeling non-core data elements, which will lead to an increase in development delivery time. Then, modeling tools can be used to quickly generate schema definitions, and are useful when rapid prototyping is required.
Table and index design
Table design is largely a compromise between flexibility and core transaction performance. In order to maintain the flexibility of the database and be able to accommodate unforeseen workloads, the table design should be very similar to the data model, and should be standardized to at least the third normal form. However, for performance purposes, certain core transactions required by users may need to be selectively denormalized.
Examples of this technique include storing pre-joined tables, adding derived columns and aggregated values. The Oracle database provides a variety of options for storing aggregated and pre-joined data through clustering and materialized view functions. These features made it possible to adopt a simpler table design initially.
Likewise, focus and resources should be used on key business tables for optimal performance. For non-critical tables, you can use shortcuts in the design to achieve faster application development. However, if prototyping and testing non-core tables become performance issues, remedial design work should be taken immediately.
Based on the SQL generated by application designers, index design is also an iterative process to a large extent. However, you can start wisely by establishing indexes that enforce primary key constraints and indexes based on known access patterns (such as names of people). As the application develops and tests the actual data volume, you may need to build better indexes to improve the performance of certain queries. When building a new index, consider the following list of index design ideas:
Append columns to an index or use an index-organized table
One of the easiest ways to speed up queries is to reduce the amount of logical I/O by eliminating access to the table from the execution plan. This can be done by appending all the columns referenced by the query to the index. These columns are the select list columns, and any necessary joins or sorting columns. This technique is particularly useful for speeding up the response time of online applications when reducing time-consuming I/O. It is best to use this method when testing an application with appropriately sized data for the first time.
The most radical form of this technology is the creation of index-organized tables (IOT). However, you must be aware that increasing the leaf size of the IOT will not harm efforts to reduce I/O.
Use other index types
There are several types of indexes available, and each index has benefits in certain situations. The following table lists the performance ideas associated with each index type.
B-tree index
These indexes are standard index types and are very suitable for primary key indexes and highly selective indexes. Used as a concatenated index, the database can use the B-tree index to retrieve data sorted by the index column.
Bitmap index
These indexes are suitable for columns with a relatively small number of different values, and the benefits of adding B-tree indexes to these columns may be limited. These indexes are suitable for data warehouse applications with low DML activity and temporary filtering modes. Combine bitmap indexes in columns to achieve high efficiency ANDand ORminimize I/O operations. In addition, through compression technology, they can generate a large number of rowids with minimal I/O. The bitmap index is particularly effective when used for query COUNT(), because the query requirements can be met in the index.
Function-based index
These indexes allow B-tree access to values derived from functions in the underlying data. Function-based indexes have some limitations in using null, and they require you to enable the query optimizer.
Function-based indexes are particularly useful when querying composite columns to produce derived results or to overcome the limitations of how data is stored in the database. An example is to query whether a certain line item in a line item exceeds a certain value. These line items are derived from (sales price-discount) x quantity (column in the table). Another example is to apply UPPERfunctions to data to allow case-insensitive searches.
Looking for exponential cost
Building and maintaining an index structure can be expensive and consume resources such as disk space, CPU, and I/O capacity. The designer must ensure that the benefits of any index outweigh the negative effects of index maintenance.
Use this simple estimation guide to index maintenance costs: each index maintenance is passed INSERT, DELETEor the UPDATEindex key needs about three times the resources as the actual DML operation on the table. Therefore, if you INSERTinsert data into a table with three indexes, the insertion speed is approximately INSERT10 times slower than that in a table without indexes. For DML, especially for INSERTheavy applications, the index design should be carefully reviewed, which may require INSERTa trade-off between query and performance.
You can also take a look:
"Oracle Database Administrator's Guide" to learn how to monitor index usage
Serialization within the index
Using sequences or timestamps to generate key values for your own indexes may cause database hotspot issues, which affect response time and throughput. This is usually the result of monotonically growing keys leading to correct index growth. To avoid this problem, try to generate keys that are inserted across the entire index range to make the workload more scalable. You can use any of the following methods to achieve:
-
Use reverse key index
-
Use hash partition index
-
Use cyclic sequence to add prefix to sequence value
-
Use scalable sequence
You can also take a look:
More information about scalable sequences in the Oracle Database Administrator's Guide
Sort columns in the index
Designers should be flexible when defining any indexing rules. Depending on your situation, use one of the following two methods to sort the keys in the index:
-
Most Orders Choose first. This method is the most commonly used method because it provides the fastest access with the least I/O, thereby minimizing the actual rowid required. This technique is mainly used for primary key and very selective range scanning.
-
Sort the columns to reduce I/O by clustering or sorting the data. In large-scale scans, you can usually reduce I/O by sorting the columns in the least selective order or sorting the data in a way that should be retrieved.
Use view
Views can speed up and simplify application design. A simple view definition can conceal the complexity of the programmer's data model. The primary task of these programmers is to retrieve, display, collect, and store data.
However, although views provide a clean programming interface, they can lead to sub-optimal, resource-intensive queries. The worst type of view used is when the view references other views and when they are combined into a query. In many cases, developers can satisfy queries directly from tables without using views. Generally, due to its inherent properties, views make it difficult for the optimizer to generate the best execution plan.
SQL execution efficiency
In the design and architecture stages of any system development, care should be taken to ensure that application developers understand SQL execution efficiency. In order to achieve this goal, the development environment must support the following features:
-
Good database connection management
Connecting to a database is an expensive operation and is highly non-scalable. Therefore, the number of concurrent connections to the database should be reduced as much as possible. A simple system where the user connects when the application is initialized is ideal. However, in Web-based or multi-tier applications, it can be difficult to use an application server to reuse database connections to users. For these types of applications, the design work should ensure that the database connection is pooled, and the database connection will not be re-established for each user request.
-
Good cursor usage and management
Maintaining user connections is also important for minimizing resolution activity on the system. Parsing is the process of interpreting SQL statements and creating execution plans for them. This process is divided into multiple stages, including syntax checking, security checking, execution plan generation, and loading the shared structure into the shared pool. There are two types of parsing operations:
-
The SQL statement was submitted for the first time, but no match was found in the shared pool. Hard parsing is the most resource-consuming and non-scalable, because hard parsing performs all operations involved in parsing.
-
A SQL statement was submitted for the first time, and the game was found in the shared pool. The match can be the result of another user's previous execution. SQL statements are shared, which is good for performance. However, soft parsing is not ideal because they still require syntax and security checks, which consume system resources.
Since parsing should be reduced as much as possible, application developers should design their applications to parse SQL statements once and execute them multiple times. This is done through the cursor. Experienced SQL programmers should be familiar with the concept of opening and re-executing cursors.
Application developers must also ensure that SQL statements are shared in the shared pool. In order to achieve this goal, use bind variables to represent the part of the query that changes between executions. If you don't do this, the SQL statement is likely to be parsed only once and will not be reused by other users. To ensure shared SQL, please use bind variables, and do not use string literals in SQL statements.
-
Implement the application
The choice of development environment and programming language largely depends on the skills available in the development team and the architectural decisions made when specifying the application. However, there are some simple performance management rules that can lead to scalable, high-performance applications.
-
Choose a development environment that suits the software components, and don't let it limit your design to determine performance. If so, you may have chosen the wrong language or environment.
-
The programming model can vary between HTML generation and direct invocation of the window system. The development method should focus on the response time of the user interface code. If you send HTML or Java over the network, try to minimize network volume and interaction.
-
Interpreted languages (such as Java and PL/SQL) are ideal for coding business logic. They are completely portable, which makes upgrading logic relatively easy. Both languages are rich in syntax to allow easy-to-read and explain code. If the business logic requires complex mathematical functions, a compiled binary language may be required. The business logic code can be located on the client computer, application server and database server. However, the application server is the most common location for business logic.
-
User requests and resource allocation
Most of them are not affected by programming languages, but tools and fourth-generation languages that obscure database connections and cursor management may use inefficient mechanisms. When evaluating these tools and environments, check their database connection models and their use of cursors and bind variables.
-
Data management and transaction
Most of them are not affected by programming languages.
-
-
When implementing a software component, please implement its function, not the function associated with other components. Implementing the function of another component leads to suboptimal design and implementation. This applies to all components.
-
Don't leave blanks on functions, and don't conduct any research on software components in design, implementation, or testing. In many cases, the gap is not discovered until the application is launched or tested in actual volume. This usually indicates poor architecture or poor initial system specifications. In the initial system design, construction and implementation process, data archiving and clearing modules are often ignored.
-
When implementing procedural logic, please implement it in a procedural language (such as C, Java or PL/SQL). When implementing data access (query) or data modification (DML), please use SQL. This rule is specific to the business logic module of the code, where procedural code is mixed with data access (non-procedural SQL) code. There is a big temptation to put procedural logic into SQL access. This often leads to bad SQL that takes up a lot of resources.
DECODESQL statements with case statements are usually candidates for optimization, and statements with a large number ofORpredicates or set operators (such asUNIONand) are also often candidates for optimizationMINUS. -
Cache frequently accessed and rarely changed data, which is expensive to obtain repeatedly. However, make this caching mechanism easy to use and ensure that it is indeed cheaper than accessing the data in the original method. This applies to all modules in which frequently used data values should be cached or stored locally, rather than repeatedly retrieved from remote or expensive data storage.
The most common examples of local cache candidates include:
-
Today's date.
SELECTSYSDATEFROMDUALCan account for more than 60% of the database workload. -
The current user name.
-
Repeated application variables and constants, such as tax rates, discount rates, or location information.
-
Local cache data can be further extended to build a local data cache in the middle layer of the application server. This helps reduce the burden on the central database server. However, care should be taken when constructing local caches, lest they become too complex and will not stop improving performance.
-
Local sequence generation.
The design implications of using caching should be considered. For example, if a user connects at midnight and the date is cached, the user's date value will become invalid.
-
-
Optimize the interface between components and ensure that all components are used in the most scalable configuration. This rule requires minimal interpretation and applies to all modules and their interfaces.
-
Use foreign key references. Enforcing referential integrity through applications is very expensive. You can maintain foreign key references by selecting the child's column value from the parent and ensuring that it exists. The foreign key constraints provided by Oracle that do not use SQL are implemented quickly, are easy to declare, and do not create network traffic.
-
Consider setting the operation and module name in the application for End-to-end application tracking. This provides greater flexibility when tracking workload issues.
Application development trends
The two biggest challenges in application development today are the increasing use of Java to replace compiled C or C++ applications, and the increasing use of object-oriented technologies, which affect the pattern design.
Java provides programmers with better code portability and usability. However, there are several aspects to Java-related performance. Because Java is an interpreted language, it executes similar logic slower than compiled languages such as C. As a result, the resource usage of the client computer has increased. This requires the application of more powerful CPUs in the client or middle-tier computers, and requires programmers to be more cautious in generating efficient code.
Because Java is an object-oriented language, it encourages the isolation of data access to classes that do not perform business logic. As a result, the programmer may call the method without knowing the efficiency of the data access method used. This often results in minimal database access and uses the simplest and most primitive database interface.
With this type of software design, the query does not always contain all valid WHEREpredicates, but instead performs row filtering in the Java program. This is very inefficient. In addition, for DML operations (especially for INSERTs), INSERTa single s will be executed, making it impossible to use the array interface. In some cases, procedure calls can reduce efficiency. Compared with actual database calls, more resources are used to move data in and out of the database.
In general, it is best to place data access calls next to business logic to achieve the best overall transaction design.
The acceptance of object-oriented at the programming level has led to the creation of object-oriented databases in Oracle Server. From BLOBstoring the object structure in s to only effectively using the database as an index card file, to using the Oracle database object relational function, this has been reflected in many ways.
If you adopt an object-oriented approach to architecture design, make sure that you do not lose the flexibility of the relational storage model. In many cases, object-oriented design methods will eventually lead to serious non-standardized data structures, which require a lot of maintenance and REFpointers associated with the object. Generally, these designs represent a step back from hierarchical and network database designs replaced by relational storage methods.
In short, if you store data in a database for a long time, and if you expect a certain degree of ad hoc query or application development in the same mode, the relational storage approach may provide the best performance and flexibility.
※ If you think the article is well written, don’t forget to give the author a thumbs up at the end of the article~
over