Is it possible to re-reference a column alias from a select clause in another column of the same select clause?

[malcolm]

Example, suppose you have these 2 tables

(NOTE: My example is totally different, but I'm simply trying to setup
the a simpler version, so excuse the bad design; not the point here)

CarsSold {
CarsSoldID int (primary key)
MonthID int
DealershipID int
NumberCarsSold int
}

Dealership {
DealershipID int, (primary key)
SalesTax decimal
}

so you may have many delearships selling cars the same month, and you
wanted a report to sum up totals of all dealerships per month.

select cs.MonthID,
sum(cs.NumberCarsSold) as 'TotalCarsSoldInMonth',
sum(cs.NumberCarsSold) * d.SalesTax as 'TotalRevenue'
from CarsSold cs
join Dealership d on d.DealershipID = cs.DealershipID
group by cs.MonthID

My question is, is there a way to achieve something like this:

select cs.MonthID,
sum(cs.NumberCarsSold) as 'TotalCarsSoldInMonth',
TotalCarsSoldInMonth * d.SalesTax as 'TotalRevenue'
from CarsSold cs
join Dealership d on d.DealershipID = cs.DealershipID
group by cs.MonthID

Notice the only difference is the 3rd column in the select. My
particular query is performing some crazy math and the only way I know
of how to get it to work is to copy and past the logic which is
getting out way out of hand...

Thanks,
Dave

[Hugo Kornelis]

On 17 May 2004 11:26:30 -0700, malcolm wrote:

Example, suppose you have these 2 tables

(NOTE: My example is totally different, but I'm simply trying to setup
the a simpler version, so excuse the bad design; not the point here)

CarsSold {
CarsSoldID int (primary key)
MonthID int
DealershipID int
NumberCarsSold int
}

Dealership {
DealershipID int, (primary key)
SalesTax decimal
}

so you may have many delearships selling cars the same month, and you
wanted a report to sum up totals of all dealerships per month.

select cs.MonthID,
sum(cs.NumberCarsSold) as 'TotalCarsSoldInMonth',
sum(cs.NumberCarsSold) * d.SalesTax as 'TotalRevenue'
from CarsSold cs
join Dealership d on d.DealershipID = cs.DealershipID
group by cs.MonthID
Hi Dave,

I can't test it right now, but this SHOULD return an error. Since you
don't group by d.SalesTax, you can't use it in the select list, unless it
is within an aggregate function. SUM(cs.NumberCarsSold * d.SalesTax)
should be okay, but that invalidates the rest of your query. May I assume
that you meant to write

select cs.MonthID, d.DealershipID,
sum(cs.NumberCarsSold) as 'TotalCarsSoldInMonth',
sum(cs.NumberCarsSold) * d.SalesTax as 'TotalRevenue'
from CarsSold cs
join Dealership d on d.DealershipID = cs.DealershipID
group by cs.MonthID, d.DealershipID, d.SalesTax


My question is, is there a way to achieve something like this:

select cs.MonthID,
sum(cs.NumberCarsSold) as 'TotalCarsSoldInMonth',
TotalCarsSoldInMonth * d.SalesTax as 'TotalRevenue'
from CarsSold cs
join Dealership d on d.DealershipID = cs.DealershipID
group by cs.MonthID

Notice the only difference is the 3rd column in the select. My
particular query is performing some crazy math and the only way I know
of how to get it to work is to copy and past the logic which is
getting out way out of hand...

Thanks,
Dave

Hi Dave,

You could try it with a derived table:

SELECT MonthID, DealershipID,
TotalCarsSoldInMonth,
TotalCarsSoldInMonth * SalesTax AS TotalRevenue
FROM (SELECT MonthID, DealershipID,
SUM(NumberCarsDold) AS TotalCarsSoldInMonth,
SalesTax
FROM CarsSold cs
JOIN Dealership d on d.DealershipID = cs.DealershipID
GROUP BY cs.MonthID, d.DealershipID, d.SalesTax) AS DerivedTable

(untested)

Best, Hugo
--

(Remove _NO_ and _SPAM_ to get my e-mail address)

[malcolm]

>

Hi Dave,

You could try it with a derived table:

SELECT MonthID, DealershipID,
TotalCarsSoldInMonth,
TotalCarsSoldInMonth * SalesTax AS TotalRevenue
FROM (SELECT MonthID, DealershipID,
SUM(NumberCarsDold) AS TotalCarsSoldInMonth,
SalesTax
FROM CarsSold cs
JOIN Dealership d on d.DealershipID = cs.DealershipID
GROUP BY cs.MonthID, d.DealershipID, d.SalesTax) AS DerivedTable

(untested)

Best, Hugo

Hello Hugo,

Thanks for the response! Very interesting, I was only curious because
some of the expressions I wrote are out of hand. Do you know if there
would be a perfermance hit by doing it this way? My guess is that
there would be but I'm not sure.

Thanks!

[Hugo Kornelis]

On 9 Jun 2004 00:40:58 -0700, malcolm wrote:

Hi Dave,

You could try it with a derived table:

SELECT MonthID, DealershipID,
TotalCarsSoldInMonth,
TotalCarsSoldInMonth * SalesTax AS TotalRevenue
FROM (SELECT MonthID, DealershipID,
SUM(NumberCarsDold) AS TotalCarsSoldInMonth,
SalesTax
FROM CarsSold cs
JOIN Dealership d on d.DealershipID = cs.DealershipID
GROUP BY cs.MonthID, d.DealershipID, d.SalesTax) AS DerivedTable

(untested)

Best, Hugo

Hello Hugo,

Thanks for the response! Very interesting, I was only curious because
some of the expressions I wrote are out of hand. Do you know if there
would be a perfermance hit by doing it this way? My guess is that
there would be but I'm not sure.

Thanks!

Hi Dave,

I'm sorry, but I can't tell. There is only one good way to find out: test
both versions, check the execution plan and check the statistics.

Best, Hugo
--

(Remove _NO_ and _SPAM_ to get my e-mail address)

[Erland Sommarskog]

malcolm (ch********@yahoo.com) writes:

You could try it with a derived table:

SELECT MonthID, DealershipID,
TotalCarsSoldInMonth,
TotalCarsSoldInMonth * SalesTax AS TotalRevenue
FROM (SELECT MonthID, DealershipID,
SUM(NumberCarsDold) AS TotalCarsSoldInMonth,
SalesTax
FROM CarsSold cs
JOIN Dealership d on d.DealershipID = cs.DealershipID
GROUP BY cs.MonthID, d.DealershipID, d.SalesTax) AS
DerivedTable

(untested)

Best, Hugo

Hello Hugo,

Thanks for the response! Very interesting, I was only curious because
some of the expressions I wrote are out of hand. Do you know if there
would be a perfermance hit by doing it this way? My guess is that
there would be but I'm not sure.

As Hugo said, testing is the only way to find out. However, the optimizer
makes a very good job with derived tables. The actual evaluation order
may not at all reflect the logical construction of the query. As long
as the result is not affected, the optimizer is free to rearrange.

--
Erland Sommarskog, SQL Server MVP, es****@sommarskog.se

Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techinf...2000/books.asp

[--CELKO--]

Short answer; no. Useful fix: use a derived table or a VIEW.

long answer, so you'll understand why:

Here is how a SELECT works in SQL ... at least in theory. Real
products will optimize things when they can.

a) Start in the FROM clause and build a working table from all of the
joins, unions, intersections, and whatever other table constructors
are there. The table expression> AS <correlation name> option allows
you give a name to this working table which you then have to use for
the rest of the containing query.

b) Go to the WHERE clause and remove rows that do not pass criteria;
that is, that do not test to TRUE (reject UNKNOWN and FALSE). The
WHERE clause is applied to the working set in the FROM clause.

c) Go to the optional GROUP BY clause, make groups and reduce each
group to a single row, replacing the original working table with the
new grouped table. The rows of a grouped table must be group
characteristics: (1) a grouping column (2) a statistic about the group
(i.e. aggregate functions) (3) a function or (4) an expression made up
those three items.

d) Go to the optional HAVING clause and apply it against the grouped
working table; if there was no GROUP BY clause, treat the entire table
as one group.

e) Go to the SELECT clause and construct the expressions in the list.
This means that the scalar subqueries, function calls and expressions
in the SELECT are done after all the other clauses are done. The "AS"
operator can also give names to expressions in the SELECT list. These
new names come into existence all at once, but after the WHERE clause,
GROUP BY clause and HAVING clause has been executed; you cannot use
them in the SELECT list or the WHERE clause for that reason.

If there is a SELECT DISTINCT, then redundant duplicate rows are
removed. For purposes of defining a duplicate row, NULLs are treated
as matching (just like in the GROUP BY).

f) Nested query expressions follow the usual scoping rules you would
expect from a block structured language like C, Pascal, Algol, etc.
Namely, the innermost queries can reference columns and tables in the
queries in which they are contained.

g) The ORDER BY clause is part of a cursor, not a query. The result
set is passed to the cursor, which can only see the names in the
SELECT clause list, and the sorting is done there. The ORDER BY
clause cannot have expression in it, or references to other columns
because the result set has been converted into a sequential file
structure and that is what is being sorted.

As you can see, things happen "all at once" in SQL, not from left to
right as they would in a sequential file/proceudral language model. In
those languages, these two statements produce different results:
**READ (a, b, c) FROM File_X;
**READ (c, a, b) FROM File_X;

while these two statements return the same data:

SELECT a, b, c FROM Table_X;
SELECT c, a, b FROM Table_X;

Think about what a confused mess this statement is in the SQL model.

SELECT f(c2) AS c1, f(c1) AS c2 FROM Foobar;

That is why such nonsense is illegal syntax.