Oracle SQL and PL/SQL Developer Best Practices Version 19c |
---|
Overview | ||
Library Note |
|
|
Our industry is full of advice, most of it of near zero value, for DBAs defining "best practice." I too have created a DBA "Best Practices"
page with the acknowledged understanding that any discussion of what is "best" in Oracle should always begin with "it depends." That said ... there are some things in SQL and PL/SQL development that should always be considered while developing a solution. This page is where I will accumulate them. |
||
Basic Principle | ||
Always code to optimize the following:
You will see that some items here are also on the DBA Best Practices page. Why? Because if the developer hasn't done a good job in the first place ... it becomes the DBA's job to clean up the inevitable mess. As you read this do not forget ... these are guidelines. What is "best" always has an "it depends" component that must be considered. |
||
Low Work | ||
1. | Code reviews are essential. If they exist take part ... if they don't start them. | |
2. Design tables based on the principle of least i/o | To minimize i/o utilize partitioning to avoid reading and writing blocks that do not need to be touched. Once you have paid for the partitioning license it is in your best interest to fully leverage this valuable asset. Most likely there are advantages in subpartitioning and reference partitioning: Consider them. | |
2. Design tables based on the principle of least cpu | Order columns such that the primary key is at the far left.
Order the columns to the right of the primary key column based on most to least frequently accessed as part of WHERE clause filtering.
The sooner you can discard a row excluded from a DML statement the less work you have performed. Then build editioning views, on top of the tables, to create a human understandable structure for queries and reports. These two tables contain the exact same information. Consider the implication if you were sending out many thousands of emails. CREATE TABLE uwclass.person1 ( |
|
3. Avoid single row processing | You have to move 100 oranges from one room to the other. You can do it one at a time or put 100 oranges in a box and make one trip: Which one is fastest? which one requires the least work? We all know the answer. Use BULK COLLECT and FORALL with the LIMIT and SAVE EXCEPTIONS clauses. | |
4. Fully qualified names | conn uwclass/uwclass@pdbdev |
|
5. Constants and variables | ||
6. Native compilation | ||
7. Alias tables and views | conn uwclass/uwclass@pdbdev |
|
8. PL/SQL Warnings | Simply put: If you do not enable PL/SQL warnings you have absolutely no idea in the world whether the PL/SQL code you are writing has major issues: Click on the link at page bottom. | |
9. Reserved Words | ||
10. Put all code into PL/SQL packages | ||
11. Secure Views | To improve source-code view security write them in the form: SELECT * FROM TABLE(pipeline_table_function); | |
Maintainable Code | ||
1. | Code reviews are essential. If they exist take part ... if they don't start them. | |
2. | Make liberal use of PRAGMA INLINE. | |
3. | ||