Comments on: How to Write “Good” SQL http://oraqa.com/2006/01/17/how-to-write-good-sql/ Oracle Question and Answer Tue, 06 Jan 2009 08:55:44 +0000 http://wordpress.org/?v=2.7 hourly 1 By: David Aldridge http://oraqa.com/2006/01/17/how-to-write-good-sql/comment-page-1/#comment-52 David Aldridge Wed, 18 Jan 2006 14:17:52 +0000 http://oraqa.com/2006/01/17/how-to-write-good-sql/#comment-52 KP, I think that this thread should be about general advice, not specific problems -- I'd suggest you go to a forum with the prob. Sorry, DA. KP,

I think that this thread should be about general advice, not specific problems — I’d suggest you go to a forum with the prob. Sorry,

DA.

]]> By: David Aldridge http://oraqa.com/2006/01/17/how-to-write-good-sql/comment-page-1/#comment-51 David Aldridge Wed, 18 Jan 2006 14:02:38 +0000 http://oraqa.com/2006/01/17/how-to-write-good-sql/#comment-51 I don't know what he question is here, KD. I don’t know what he question is here, KD.

]]> By: kirtandesai http://oraqa.com/2006/01/17/how-to-write-good-sql/comment-page-1/#comment-48 kirtandesai Wed, 18 Jan 2006 13:15:15 +0000 http://oraqa.com/2006/01/17/how-to-write-good-sql/#comment-48 True... A question for u.. _________________________ SELECT * FROM Budget_Table WHERE SCEN_ID IN ('FIN', 'ACT') AND STAT_CD = 'ACT' AND LED_ID 'EB_RC' AND Budget_Table.ROW_TMSTMP True…
A question for u..
_________________________
SELECT *
FROM
Budget_Table
WHERE
SCEN_ID IN (’FIN’, ‘ACT’) AND STAT_CD = ‘ACT’ AND LED_ID ‘EB_RC’
AND
Budget_Table.ROW_TMSTMP

]]> By: David Aldridge http://oraqa.com/2006/01/17/how-to-write-good-sql/comment-page-1/#comment-41 David Aldridge Wed, 18 Jan 2006 01:43:07 +0000 http://oraqa.com/2006/01/17/how-to-write-good-sql/#comment-41 I'd say that you would have to know that, but it isn't within the intended scope of the article. I’d say that you would have to know that, but it isn’t within the intended scope of the article.

]]> By: kirtandesai http://oraqa.com/2006/01/17/how-to-write-good-sql/comment-page-1/#comment-40 kirtandesai Wed, 18 Jan 2006 00:55:50 +0000 http://oraqa.com/2006/01/17/how-to-write-good-sql/#comment-40 I agree, SQL proficiency comes first. but one must know or find out a perfect time to shift gears from step 3 to step 6. waht sya yuo? Kd I agree,
SQL proficiency comes first. but one must know or find out a perfect time to shift gears from step 3 to step 6.

waht sya yuo?
Kd

]]> By: David Aldridge http://oraqa.com/2006/01/17/how-to-write-good-sql/comment-page-1/#comment-39 David Aldridge Tue, 17 Jan 2006 23:06:36 +0000 http://oraqa.com/2006/01/17/how-to-write-good-sql/#comment-39 I'd agree that there are some prerequisites to good SQL performance -- for example that the design of the database be competently implemented, that appropriate indexes are in place, that you understand and make the best use of the optimizer. I guess that point 3 is "Know when to stop tuning". I'd be wary of directing people to materialized views as a performance enhancer at an early stage in their development experience. IMHO SQL proficiency comes first. I’d agree that there are some prerequisites to good SQL performance — for example that the design of the database be competently implemented, that appropriate indexes are in place, that you understand and make the best use of the optimizer.

I guess that point 3 is “Know when to stop tuning”.

I’d be wary of directing people to materialized views as a performance enhancer at an early stage in their development experience. IMHO SQL proficiency comes first.

]]> By: kirtandesai http://oraqa.com/2006/01/17/how-to-write-good-sql/comment-page-1/#comment-38 kirtandesai Tue, 17 Jan 2006 22:44:23 +0000 http://oraqa.com/2006/01/17/how-to-write-good-sql/#comment-38 I think we can go to an extent on optimizing sql. following are the steps that i try to follow. Apart from the following, query optimization has a lot to do with client requirement especially in case of transactional databases. (believe it or not) [Not in any particular order] 1. A reasonable normalization of the logical database design. 2. Use Efficient Index Design 3. some queries are resource-intensive by nature. keep in mind that they r not in-efficient. SQL, by nature, is also set-oriented. 4. Make changes to optimizer_mode, optimizer_index_cost_adj and optimizer_index_caching 5. Use the dbms_stats package to import specialized statistics. Ones which are geared to the current processing mode. 6. Use Oracle Materialized Views to pre-aggregate and pre-summarize data to reduce the amount of run-time table joins. For low-update databases, you can also pre-join tables together to improve processing speed. well...gotta go.. at work...will add some more to the list whenever possible. ANY THOUGHTS DAVID? KD I think we can go to an extent on optimizing sql. following are the steps that i try to follow. Apart from the following, query optimization has a lot to do with client requirement especially in case of transactional databases. (believe it or not)
[Not in any particular order]
1. A reasonable normalization of the logical database design.
2. Use Efficient Index Design
3. some queries are resource-intensive by nature. keep in mind that they r not in-efficient. SQL, by nature, is also set-oriented.
4. Make changes to optimizer_mode, optimizer_index_cost_adj and optimizer_index_caching
5. Use the dbms_stats package to import specialized statistics. Ones which are geared to the current processing mode.
6. Use Oracle Materialized Views to pre-aggregate and pre-summarize data to reduce the amount of run-time table joins. For low-update databases, you can also pre-join tables together to improve processing speed.

well…gotta go.. at work…will add some more to the list whenever possible.

ANY THOUGHTS DAVID?

KD

]]> By: David Aldridge http://oraqa.com/2006/01/17/how-to-write-good-sql/comment-page-1/#comment-33 David Aldridge Tue, 17 Jan 2006 20:03:43 +0000 http://oraqa.com/2006/01/17/how-to-write-good-sql/#comment-33 Of course ... Of course …

]]> By: kirtandesai http://oraqa.com/2006/01/17/how-to-write-good-sql/comment-page-1/#comment-31 kirtandesai Tue, 17 Jan 2006 19:17:28 +0000 http://oraqa.com/2006/01/17/how-to-write-good-sql/#comment-31 I agree to your views on this topic. I do believe that SQL should be able to perform at it's best. But also, there is a thin line between writing a top-notch efficient SQL and compromizing a lil bit on performance. Can we also talk about that? I agree to your views on this topic. I do believe that SQL should be able to perform at it’s best. But also, there is a thin line between writing a top-notch efficient SQL and compromizing a lil bit on performance.
Can we also talk about that?

]]>