Archives of the TeradataForum

Message Posted: Mon, 14 Nov 2005 @ 16:37:47 GMT

	<Prev	Next>		<<First	<Prev	Next>	Last>>

Hi Glen:

I will take responsiblity for maybe not being as clear as I could have been in my posting on this topic. I say this because you are actually agreeing with me. An SP is a great tool for doing administrative work like creating and dropping tables, monitoring space and a variety of this tasks that are more serial in nature. For instance, you cannot insert a row in a table until it is created.

My main point was that an SP is like writing a program and therefore serial in nature. You cannot view or return a row unless you have declared, opened and fetched the cursor to manage SPOOL when handling more than a single row. Teradata, as we all know, populates SPOOL and can populate a table in parallel when we use the proper tool(s). It appears from Teradata classes that I have taught to many people with Oracle experience that there is a strong tendency and somewhat of a requirement in Oracle to use SP's to accomplish many intricate tasks. To a large degree I have been told by many of these same people that the requirement comes from the inflexibility of Oracle SQL or that it is always more of a monolitic instead of parallel approach to returning the desired answer set. As a simple example - most people have been discouraged from using a co-related subquery and OLAP processing in Oracle because it is so slow. It is highly encouraged in Teradata because of its parallel execution (even parallel steps within a single execution). Now this is power!!! If we think we only have a hammer, everything starts to look like a nail, even the ones with grooves - works better when a screwdriver is applied.

My point was that if you take away the power of parallel processing (even for a moment in time) Teradata starts looking more like Oracle and these sites are now using Teradata because Oracle fell on its face. It is time to think in parallel and implement accordingly instead of trying to simply make an application flat tire inflate with more speed. I don't watch many NASCAR races, but everytime I have seen a flat tire occur during a race the driver came to the pits instead of going faster and risking hitting the wall (if it didn't happen as a direct result of the flat). Isn't this along the same lines as simply taking Oracle table creates and making the PK the UPI when it doesn't necessarily provide the best join performance as a merge join type 2 instead of type 1? PDBD says we need to also evaluate the way we use the data and not strictly look at even distribution - right tool for the job.

I hope this better explains my original intent. Again, I agree whole-heartedly that an SP is a fantastic tool for administrative operations to automate them and therefore SP's didn't come a day too soon and they are one of my favorite topics in a class. But then, I am an old COBOL and PL/1 application programmer...LOL

Regards,

Michael Larkins
Certified Teradata Master
Certified Teradata SQL Instructor
Teradata SQL - Unleash the Power

	<Prev	Next>		<<First	<Prev	Next>	Last>>