<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:georss="http://www.georss.org/georss" xmlns:geo="http://www.w3.org/2003/01/geo/wgs84_pos#" xmlns:media="http://search.yahoo.com/mrss/"
		>
<channel>
	<title>Comments on: An Alternative way of writing Effdt clauses</title>
	<atom:link href="http://peoplesofttipster.com/2007/10/07/an-alternative-way-of-writing-effdt-clauses/feed/" rel="self" type="application/rss+xml" />
	<link>http://peoplesofttipster.com/2007/10/07/an-alternative-way-of-writing-effdt-clauses/</link>
	<description>A PeopleSoft Tips and Tricks Blog</description>
	<lastBuildDate>Wed, 14 Dec 2011 14:35:44 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.com/</generator>
	<item>
		<title>By: PeopleSoft Tipster</title>
		<link>http://peoplesofttipster.com/2007/10/07/an-alternative-way-of-writing-effdt-clauses/#comment-801</link>
		<dc:creator><![CDATA[PeopleSoft Tipster]]></dc:creator>
		<pubDate>Mon, 23 Jun 2008 14:37:27 +0000</pubDate>
		<guid isPermaLink="false">http://peoplesofttipster.com/2007/10/07/an-alternative-way-of-writing-effdt-clauses/#comment-801</guid>
		<description><![CDATA[This perhaps isn&#039;t the place to get involved in a &#039;do analytics work&#039; debate.  They give greater database performance and developer productivity, and the gain is - in general - larger the greater the volume of data analysed.  

Saying that, there will obviously be exceptions, and as I said in the article title, this is an alternative - at no point did I say &#039;everyone should always do it this way from now forwards&#039;.  Before deciding what&#039;s right for you investigate all methods and chose the fastest.  Most of the time, that&#039;ll be the analytic method due to reduced passes over the data through the use of partition result sets, and hence leading to fewer queries/subqueries (cutting out self-joins particularly), but not always.

I&#039;ve used the functions on significantly larger data volumes than 320,000 rows and they&#039;ve saved me much time and effort.]]></description>
		<content:encoded><![CDATA[<p>This perhaps isn&#8217;t the place to get involved in a &#8216;do analytics work&#8217; debate.  They give greater database performance and developer productivity, and the gain is &#8211; in general &#8211; larger the greater the volume of data analysed.  </p>
<p>Saying that, there will obviously be exceptions, and as I said in the article title, this is an alternative &#8211; at no point did I say &#8216;everyone should always do it this way from now forwards&#8217;.  Before deciding what&#8217;s right for you investigate all methods and chose the fastest.  Most of the time, that&#8217;ll be the analytic method due to reduced passes over the data through the use of partition result sets, and hence leading to fewer queries/subqueries (cutting out self-joins particularly), but not always.</p>
<p>I&#8217;ve used the functions on significantly larger data volumes than 320,000 rows and they&#8217;ve saved me much time and effort.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Matthew Jacobson</title>
		<link>http://peoplesofttipster.com/2007/10/07/an-alternative-way-of-writing-effdt-clauses/#comment-794</link>
		<dc:creator><![CDATA[Matthew Jacobson]]></dc:creator>
		<pubDate>Tue, 10 Jun 2008 20:09:37 +0000</pubDate>
		<guid isPermaLink="false">http://peoplesofttipster.com/2007/10/07/an-alternative-way-of-writing-effdt-clauses/#comment-794</guid>
		<description><![CDATA[This is not complete information. The &#039;faster execution&#039; only applies when you have a relatively low number of job rows in your PS_JOB table. The more rows you have the faster method A will be compared to Method B.

With 320,000 rows in PS_JOB - 

cost for A is 24,020
cost for B is 40,912

I&#039;d suggest sticking with the obvious approach rather than attempting to use fancy analytical clauses.]]></description>
		<content:encoded><![CDATA[<p>This is not complete information. The &#8216;faster execution&#8217; only applies when you have a relatively low number of job rows in your PS_JOB table. The more rows you have the faster method A will be compared to Method B.</p>
<p>With 320,000 rows in PS_JOB &#8211; </p>
<p>cost for A is 24,020<br />
cost for B is 40,912</p>
<p>I&#8217;d suggest sticking with the obvious approach rather than attempting to use fancy analytical clauses.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: PeopleSoft Tipster</title>
		<link>http://peoplesofttipster.com/2007/10/07/an-alternative-way-of-writing-effdt-clauses/#comment-759</link>
		<dc:creator><![CDATA[PeopleSoft Tipster]]></dc:creator>
		<pubDate>Fri, 09 May 2008 00:16:03 +0000</pubDate>
		<guid isPermaLink="false">http://peoplesofttipster.com/2007/10/07/an-alternative-way-of-writing-effdt-clauses/#comment-759</guid>
		<description><![CDATA[There are no issues with using this method in a multi-join query.  You&#039;d just list the next table after the alias on the inline view like this:

 SELECT J.emplid, J.empl_rcd, J.effdt, J.effseq, P.NAME
  FROM (
SELECT emplid, empl_rcd, effdt, effseq,
  RANK () OVER
       (PARTITION BY emplid, empl_rcd
            ORDER BY effdt DESC
                   , effseq DESC) rnk
           FROM ps_job
          WHERE effdt &lt;= ‘10/AUG/2007′) j,
 PS_PERSONAL_DATA P
 WHERE j.rnk = 1
and p.emplid = j.emplid

(This SQL hasn&#039;t been tested, so I may have typo&#039;ed or missed something obvious, but hopefully the method is clear)]]></description>
		<content:encoded><![CDATA[<p>There are no issues with using this method in a multi-join query.  You&#8217;d just list the next table after the alias on the inline view like this:</p>
<p> SELECT J.emplid, J.empl_rcd, J.effdt, J.effseq, P.NAME<br />
  FROM (<br />
SELECT emplid, empl_rcd, effdt, effseq,<br />
  RANK () OVER<br />
       (PARTITION BY emplid, empl_rcd<br />
            ORDER BY effdt DESC<br />
                   , effseq DESC) rnk<br />
           FROM ps_job<br />
          WHERE effdt &lt;= ‘10/AUG/2007′) j,<br />
 PS_PERSONAL_DATA P<br />
 WHERE j.rnk = 1<br />
and p.emplid = j.emplid</p>
<p>(This SQL hasn&#8217;t been tested, so I may have typo&#8217;ed or missed something obvious, but hopefully the method is clear)</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: fambaus</title>
		<link>http://peoplesofttipster.com/2007/10/07/an-alternative-way-of-writing-effdt-clauses/#comment-757</link>
		<dc:creator><![CDATA[fambaus]]></dc:creator>
		<pubDate>Tue, 06 May 2008 13:29:50 +0000</pubDate>
		<guid isPermaLink="false">http://peoplesofttipster.com/2007/10/07/an-alternative-way-of-writing-effdt-clauses/#comment-757</guid>
		<description><![CDATA[Excellent tip. What about in a multi join query?]]></description>
		<content:encoded><![CDATA[<p>Excellent tip. What about in a multi join query?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Noons</title>
		<link>http://peoplesofttipster.com/2007/10/07/an-alternative-way-of-writing-effdt-clauses/#comment-396</link>
		<dc:creator><![CDATA[Noons]]></dc:creator>
		<pubDate>Mon, 08 Oct 2007 12:12:52 +0000</pubDate>
		<guid isPermaLink="false">http://peoplesofttipster.com/2007/10/07/an-alternative-way-of-writing-effdt-clauses/#comment-396</guid>
		<description><![CDATA[Excellent!  Thanks for the great hint on analytics.
I always suspected they could b effectively used for Peoplesoft and their quaint timeseries format, this just confirms it.

Will definitely give it a go.]]></description>
		<content:encoded><![CDATA[<p>Excellent!  Thanks for the great hint on analytics.<br />
I always suspected they could b effectively used for Peoplesoft and their quaint timeseries format, this just confirms it.</p>
<p>Will definitely give it a go.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

