Comments on: Mantra on data processing http://tonguc.wordpress.com Extract(Read) > Transform(Test&Apply) > Load(Learn) Wed, 09 Dec 2009 19:53:13 +0000 http://wordpress.com/ hourly 1 By: H.Tonguç Yılmaz http://tonguc.wordpress.com/universal-mantra-on-data-intensive-processing/#comment-81 H.Tonguç Yılmaz Wed, 04 Apr 2007 19:15:15 +0000 http://tonguc.wordpress.com/universal-mantra-on-data-intensive-processing/#comment-81 hicamel thank you for your comment, I totally agree with you in terms of flexibility and maintainability of the developed application. But there are sometimes some constraints you have to obey the performance needs for example of a legal problem. I experienced several examples, until it was over I didnt wanted to go for the analytics solution where pipelined plsql should handle, but at the end it was a legal issue and it had to be finished within some time frame that we had no alternative but anaytics. Cost was of course inevitable after some change needed, it was death of pain to modify some several pages of analytics for the new requests. Best regards, Tonguc hicamel thank you for your comment, I totally agree with you in terms of flexibility and maintainability of the developed application.

But there are sometimes some constraints you have to obey the performance needs for example of a legal problem. I experienced several examples, until it was over I didnt wanted to go for the analytics solution where pipelined plsql should handle, but at the end it was a legal issue and it had to be finished within some time frame that we had no alternative but anaytics.

Cost was of course inevitable after some change needed, it was death of pain to modify some several pages of analytics for the new requests.

Best regards,
Tonguc

]]> By: hicamel http://tonguc.wordpress.com/universal-mantra-on-data-intensive-processing/#comment-80 hicamel Tue, 03 Apr 2007 23:17:24 +0000 http://tonguc.wordpress.com/universal-mantra-on-data-intensive-processing/#comment-80 regarding: You should do it in a single SQL statement if at all possible I have to disagree. I have written single SQL statements that were pages long and found later that I really regreted doing so. The problem with doing everything in a single statement is debugging. When the results of your query are not right and you need to figure out why, with a complex query you are out of luck. If you break the query down into several smaller queries the debugging becomes easy. I would say, "you should use PL/SQL and break the code into small pieces UNLESS performance is a problem. If performance is a problem, then start combining the smaller SQL statement where possible" regards, Mike regarding: You should do it in a single SQL statement if at all possible

I have to disagree. I have written single SQL statements that were pages long and found later that I really regreted doing so. The problem with doing everything in a single statement is debugging. When the results of your query are not right and you need to figure out why, with a complex query you are out of luck. If you break the query down into several smaller queries the debugging becomes easy.

I would say, “you should use PL/SQL and break the code into small pieces UNLESS performance is a problem. If performance is a problem, then start combining the smaller SQL statement where possible”

regards,
Mike

]]> By: Some migration experiences to share « H.Tonguç YILMAZ Oracle Blog http://tonguc.wordpress.com/universal-mantra-on-data-intensive-processing/#comment-60 Some migration experiences to share « H.Tonguç YILMAZ Oracle Blog Sat, 17 Mar 2007 15:39:28 +0000 http://tonguc.wordpress.com/universal-mantra-on-data-intensive-processing/#comment-60 [...] have to choose a migration methodology which reduces the I/O, and remember the mantra on data intensive processing; Create table as select(CTAS), merge statement or conditional multi-table inserts and dbms_errlog [...] [...] have to choose a migration methodology which reduces the I/O, and remember the mantra on data intensive processing; Create table as select(CTAS), merge statement or conditional multi-table inserts and dbms_errlog [...]

]]> By: Oracle SQL Extentions Part 1 « H.Tonguç YILMAZ Oracle Blog http://tonguc.wordpress.com/universal-mantra-on-data-intensive-processing/#comment-17 Oracle SQL Extentions Part 1 « H.Tonguç YILMAZ Oracle Blog Sun, 07 Jan 2007 06:40:19 +0000 http://tonguc.wordpress.com/universal-mantra-on-data-intensive-processing/#comment-17 [...] Part 1 Filed under: Oracle Performance, Oracle HowToS — H.Tonguç Yılmaz @ 6:39 am Universal mantra on data intensive processing advices that “You should do it in a single SQL statement if at all [...] [...] Part 1 Filed under: Oracle Performance, Oracle HowToS — H.Tonguç Yılmaz @ 6:39 am Universal mantra on data intensive processing advices that “You should do it in a single SQL statement if at all [...]

]]> By: Which one perform better for the same job : Oracle Function or Oracle View « H.Tonguç YILMAZ Oracle Blog http://tonguc.wordpress.com/universal-mantra-on-data-intensive-processing/#comment-8 Which one perform better for the same job : Oracle Function or Oracle View « H.Tonguç YILMAZ Oracle Blog Mon, 01 Jan 2007 16:06:22 +0000 http://tonguc.wordpress.com/universal-mantra-on-data-intensive-processing/#comment-8 [...] So view option used less latching and ran faster(older releases will show a larger disparity between the run times). Again time to remember the “Universal mantra on data intensive processing” : don’t use plsql when plain old sql will do it for you ;) [...] [...] So view option used less latching and ran faster(older releases will show a larger disparity between the run times). Again time to remember the “Universal mantra on data intensive processing” : don’t use plsql when plain old sql will do it for you ;) [...]

]]>