Anybody can help with this SQL?

Question

The table is simple, only 2 columns:
create table personpay(
id integer primary key,
pay number(8,2) not null);
So the original talbe looks like this:
ID PAY
1 800
2 400
3 1200
4 500
5 600
6 1900
The requirement is to use one single query(no pl/sql) to show something lile the following, in other words, for each ID, the pay is the sum of all before itself and itself. So the query result looks like this:
ID PAY
1 800
2 1200
3 2400
4 2900
5 3500
6 5400
Again, just use one sql. No pl/sql. Anybody can help with this? I really appreciate that.
thanks,

Answer 1

Eh, people are so "analytically minded" that can't even notice a simple join?
Counting Ordered Rows
Let’s start with a basic counting problem. Suppose we are given a list of integers, for example:
x
2
3
4
6
9
and want to enumerate all of them sequentially like this:
x      #
2      1
3      2
4      3
6      4
9      5
Enumerating rows in the increasing order is the same as counting how many rows precede a given row.
SQL enjoys success unparalleled by any rival query language. Not the last reason for such popularity might be credited to its proximity to English . Let examine the informal idea
Enumerating rows in increasing order is counting how many rows precede a given row.
carefully. Perhaps the most important is that we referred to the rows in the source table twice: first, to a given row, second, to a preceding row. Therefore, we need to join our number list with itself (fig 1.1).
Cartesian Product
Surprisingly, not many basic SQL tutorials, which are so abundant on the web today, mention Cartesian product. Cartesian product is a join operator with no join condition
select A.*, B.* from A, B
Figure 1.1: Cartesian product of the set A = {2,3,4,6,9} by itself. Counting all the elements x that are no greater than y produces the sequence number of y in the set A.
Carrying over this idea into formal SQL query is straightforward. As it is our first query in this book, let’s do it step by step. The Cartesian product itself is
select t.x x, tt.x y
from T t, T tt
Next, the triangle area below the main diagonal is
select t.x x, tt.x y
from T t, T tt
where tt.x <= t.x
Finally, we need only one column – t.x – which we group the previous result by and count
select t.x, count(*) seqNum
from T t, T tt
where tt.x <= t.x
group by t.x
What if we modify the problem slightly and ask for a list of pairs where each number is coupled with its predecessor?
x      predecessor
2      
3      2
4      3
6      4
9      6
Let me provide a typical mathematician’s answer, first -- it is remarkable in a certain way. Given that we already know how to number list elements successively, it might be tempted to reduce the current problem to the previous one:
Enumerate all the numbers in the increasing order and match each sequence number seq# with predecessor seq#-1. Next!
This attitude is, undoubtedly, the most economical way of thinking, although not necessarily producing the most efficient SQL. Therefore, let’s revisit our original approach, as illustrated on fig 1.2.
Figure 1.2: Cartesian product of the set A = {2,3,4,6,9} by itself. The predecessor of y is the maximal number in a set of x that are less than y. There is no predecessor for y = 2.
This translates into the following SQL query
select t.x, max(tt.x) predecessor
from T t, T tt
where tt.x < t.x
group by t.x
Both solutions are expressed in standard SQL leveraging join and grouping with aggregation. Alternatively, instead of joining and grouping why don’t we calculate the count or max just in place as a correlated scalar subquery:
select t.x,
(select count(*) from T tt where tt.x <= t.x) seq#
from T t
group by t.x
The subquery always returns a single value; this is why it is called scalar. The tt.x <= t.x predicate connects it to the outer query; this is why it is called correlated. Arguably, leveraging correlated scalar subqueries is one the most intuitive techniques to write SQL queries.
How about counting rows that are not necessarily distinct? This is where our method breaks. It is challenging to distinguish duplicate rows by purely logical means, so that various less “pure” counting methods were devised. They all, however, require extending the SQL syntactically, which was the beginning of slipping along the ever increasing language complexity slope.
Here is how analytic SQL extension counts rows
select x, rank() over(order by x) seq# from T; -- first problem
select x, lag() over(order by x) seq# from T; -- second problem
Many people suggest that it’s not only more efficient, but more intuitive. The idea that “analytics rocks” can be challenged in many ways. The syntactic clarity has its cost: SQL programmer has to remember (or, at least, lookup) the list of analytic functions. The performance argument is not evident, since non-analytical queries are simpler construction from optimizer perspective. A shorter list of physical execution operators implies fewer query transformation rules, and less dramatic combinatorial explosion of the optimizer search space.
It might even be argued that the syntax could be better. The partition by and order by clauses have similar functionality to the group by and order by clauses in the main query block. Yet one name was reused, and the other had been chosen to have a new name. Unlike other scalar expressions, which can be placed anywhere in SQL query where scalar values are accepted, the analytics clause lives in the scope of the select clause only. I have never been able to suppress an impression that analytic extension could be designed in more natural way.