1. Always define field names. Do not use SELECT * or INSERT INTO table VALUES. However, if it's important enough to save in a text file (ie, it's seed data or a migration script) then it gets explicit field names.
2. Always use the database server's timestamp. Web servers may have disparate times. Reports may come from different servers than the inserted data.
3. When doing reports, the network traffic is usually the biggest bottleneck. If you're going to receive information, it's better to receive in chunks, which will likely be larger than a logical piece. For instance, state reporting -- instead of making 50 connections for states in the US, get them all at once. If the dataset is very large and folks do not want to stare at a blank page while the report is loading, use paging with LIMIT to grab, say, 1000 entries at a time and display them on the screen so people can start looking at the data while the rest is being grabbed.
4. Running a query in a loop is usually a bad idea. If you are executing the same query with different data, consider building a query string using UNION and executing it at the end of the loop, so you can execute multiple queries with only one trip across the network to the database.
5. Do not be afraid of JOINs. They are not necessarily resource intensive, given good indexing. Most of the time a denormalized schema without a join ends up being worse than a normalized one using a join. When there is redundant data, ensuring data integrity takes up more cycles than providing a framework for data integrity in the first place.
6. Limit the use of correlated subqueries; often they can be replaced with a JOIN.
7. Ensure repeated sql statements are written absolutely identical to facilitate efficient reuse: reparsing can often be avoided for each subsequent use.
8. Code the SQL as per exact requirement i.e. no unnecessary columns should be selected, and no unnecessary GROUP BY or ORDER BY clauses used.
DevStd_Database_SQL_V1.0 6 / 7
9. Avoid using ‘select *’, when you could select by actual column name(s). It is the same or faster to SELECT by actual column name(s). The larger the table the more likely the savings. E.g. SELECT customer_id, last_name, first_name, street, city FROM customer; rather than: SELECT * FROM customer;
10. Do not perform operations on DB objects referenced in the WHERE clause. For e.g. use “SELECT client, date, amount FROM sales WHERE amount > 0” rather than “SELECT client, date, amount FROM sales WHERE amount!= 0”.
11. Use HAVING only when summary operations applied to columns will be restricted by the clause. Avoid a HAVING clause in SELECT statements when it is only required to filter selected rows after all the rows have been returned. A WHERE clause may be more efficient. For e.g. use “SELECT city FROM country WHERE city!= 'Vancouver' AND city!= 'Toronto' GROUP BY city” rather than “SELECT city FROM country GROUP BY city HAVING city!= 'Vancouver' AND city!= 'Toronto'”
12. Where possible use EXISTS rather than DISTINCT.
13. Where possible use a non-column expression (putting the column on one side of the operator and all the other values on the other). Non-column expressions are often processed earlier thereby speeding the query. For e.g. use WHERE SALES < 1000/(1 + n); rather than “WHERE SALES + (n * SALES) < 1000”. Never do a calculation on an indexed column (For e.g., WHERE salary*5 > :myvalue).
14. Whenever possible, use the UNION statement instead of OR conditions.
15. Avoid the use of NOT IN or HAVING in the WHERE clause. Instead, use the NOT EXISTS clause.
16. Use the Oracle “decode” function to minimize the number of times a table has to be selected.
17. Check whether your query could do without the DISTINCT clause you have in the code.
18. Check whether UNION be replaced with a UNION ALL which improves the response time.
DevStd_Database_SQL_V1.0 7 / 7
19. Avoid using negative logic (NOT, <>, !=).
20. When using OR’s in the where clause be sure to use enough parenthesis to ensure defaults for operator precedence are not used.
21. When we use ‘EXISTS’, we do not need to use any column name in the subsequent SQL and just return a constant value for better efficiency. For e.g. SELECT s.sname FROM student s
WHERE EXISTS (SELECT 1 FROM grade_report gr, section WHERE section.section_id = gr.section_id).
22. Ensure all Foreign Key columns are indexed
23. Use Bind Variables instead of static values