Oracle programming Art Study Notes (2)-developed successful Oracle Applications

 

Thomas Kyte summed up his successful experience in Oracle programming art, which is excerpted as follows:

 

Summary of successful experiences:

· Whether applications built based on databases (or databases) are successful depends on how databases are used. In addition, from my experience, all applications are built around databases. If an application does not store data permanently anywhere, it is hard to imagine that the application is really useful.

· Applications are always "coming and going", and different data will always exist. In the long run, our goal is not to build applications, but to use the underlying data of these applications.

· The development team must have database-proficient developers who are responsible for ensuring that the database logic is reliable and that the system can be built smoothly. If it is a fact (the application has been deployed) before optimization, it usually indicates that you did not seriously consider these issues during development.

 

Key Points of Oracle development:

· Understand the Oracle architecture. You do not need to be proficient in overwriting servers on your own, but you do need to be familiar with the meaning of using a specific feature.

· Understand locking and concurrency control features, and know that each database implements these features in different ways. If you do not know this, your database may give a "wrong" answer, and the application may encounter serious competition problems, so that the performance is low.

· Do not treat the database as a black box, that is, do not think that you do not need to understand the database. In most applications, databases are the most important part. If you ignore it, the consequences are fatal.

· Use the built-in functions provided by Oracle as much as possible to solve the problem. This is what you bought at a high price. Software projects, programming languages, and frameworks are constantly changing. As a developer, we hope to establish and run the system within weeks (maybe months) and solve the next problem. If you start from scratch to "CREATE" again, you will never be able to catch up with the pace of development. You certainly won't use Java to create your own hash, Because Java already provides a hash, and you should also use the available database functions at hand. Of course, the first step is to know which database functions are available.

 

Too many people regard the database as a black box, as if they do not need to understand its input. If you think about it in this way, it will often be misled: if you do not know the database, you will be unable to proceed.

Specifically, you need to understand the following:

· Database architecture, how databases work, and how they behave.

· What is concurrency control? What Does concurrency control mean to you.

· Performance, scalability, and security are all requirements that should be taken into account during development. design should be made appropriately and should not be expected to meet these requirements.

· How to Implement database features. The actual implementation of a specific database feature may be different from what you think. You must design based on how the database actually works (rather than thinking how it should work.

· What features does the database provide and why the features provided by the database are superior to self-built features.

· Why is it not enough to get a rough understanding of SQL? You need to learn more about SQL.

· Both DBAs and developers are working towards the same goal. They are not two rival camps, but do not want to be smarter than the target in each round.

 

Based on experience, more than 80% (or even 100%) of performance problems occur at the design and implementation level, rather than at the database level. By modifying applications, I often increase performance by an order of magnitude.

However, it is unlikely that such a huge improvement will be made only at the database level. Do not optimize databases before optimizing applications running on databases.

 

From: NowOrNever