dbTalk Databases Forums  

Query Variables

comp.databases.ms-sqlserver comp.databases.ms-sqlserver


Discuss Query Variables in the comp.databases.ms-sqlserver forum.



Reply
 
Thread Tools Display Modes
  #1  
Old   
Yota
 
Posts: n/a

Default Query Variables - 10-13-2007 , 05:01 PM






Hi,

I'm new to SQL Server, but an experienced .Net developer. I'm trying
to accomplish a query the most efficient way possible. My question is
if you can define a temporary variable within a query to store tables
or fields. (Like the LET clause of LINQ) My query makes use of
subqueries which filter my table (WHEREs, not SELECTs) in the same
exact way. I'd like to have a subquery at the beginning of my query
to filter the table(s) once, and then SELECT off it of later in the
query.

Here is an (utterly poor) example. No, this is not from my project.
My filter is a little more complex than 'c=@p'.
('c' is a column/field, 't' is a table', '@p' is a parameter)

SELECT *
FROM (SELECT COUNT(c) FROM t WHERE c=@p GROUP BY c)
CROSS JOIN (SELECT c FROM t WHERE c=@p)

Bottom line, would something like the following be possible?

@v = (SELECT c FROM t WHERE a=@p)
SELECT *
FROM (SELECT COUNT(c) FROM @v GROUP BY c)
CROSS JOIN (SELECT c FROM @v)

I'd like to know if this is possible within a query, but I can move to
a Stored Procedure if I must. (I'll still need help then.)

Thank you all


Reply With Quote
  #2  
Old   
Erland Sommarskog
 
Posts: n/a

Default Re: Query Variables - 10-13-2007 , 05:16 PM






Yota (yotaxp (AT) gmail (DOT) com) writes:
Quote:
I'm new to SQL Server, but an experienced .Net developer. I'm trying
to accomplish a query the most efficient way possible. My question is
if you can define a temporary variable within a query to store tables
or fields. (Like the LET clause of LINQ) My query makes use of
subqueries which filter my table (WHEREs, not SELECTs) in the same
exact way. I'd like to have a subquery at the beginning of my query
to filter the table(s) once, and then SELECT off it of later in the
query.

Here is an (utterly poor) example. No, this is not from my project.
My filter is a little more complex than 'c=@p'.
('c' is a column/field, 't' is a table', '@p' is a parameter)

SELECT *
FROM (SELECT COUNT(c) FROM t WHERE c=@p GROUP BY c)
CROSS JOIN (SELECT c FROM t WHERE c=@p)

Bottom line, would something like the following be possible?

@v = (SELECT c FROM t WHERE a=@p)
SELECT *
FROM (SELECT COUNT(c) FROM @v GROUP BY c)
CROSS JOIN (SELECT c FROM @v)

I'd like to know if this is possible within a query, but I can move to
a Stored Procedure if I must. (I'll still need help then.)
Syntactically you can do:

WITH MyCount AS (
SELECT c FROM t WHERE a = @p
)
SELECT *
FROM (SELECT COUNT(c) FROM MyCount GROUP BY c) AS a
CROSS JOIN (SELECT c FROM MyCount) AS b

The WITH clause defines a common table expression (CTE), to which you can
refer for the rest of the query as if it was a table. However, this is
main syntactic sugar: in SQL 2005, SQL Server will always compute the
expression everytime it occur, and never consider to put the result
into a worktable. This could be different in a future version of SQL Server.

If you want to store an intermediate result, you need to use a table
variable or a temp table.

Some more notes on WITH:
1) The statement that precedes WITH must have a ; as statement terminator.
2) WITH is actually not only syntactic sugar: a CTE can refer to itself
under some circumstances, permitting you to wind up recursive
structures.


--
Erland Sommarskog, SQL Server MVP, esquel (AT) sommarskog (DOT) se

Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/pro...ads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodinf...ons/books.mspx


Reply With Quote
  #3  
Old   
steve
 
Posts: n/a

Default Re: Query Variables - 10-15-2007 , 02:19 AM



Quote:
My question is if you can define a temporary variable within a query to >store tablesor fields. (Like the LET clause of LINQ).
The answer is of course! Jump in anywhere and you will see what makes
sense You can start here:
http://beyondsql.blogspot.com/2007/0...variables.html

best,.
www.beyondsql.blogspot.com



Reply With Quote
  #4  
Old   
Ed Murphy
 
Posts: n/a

Default Re: Query Variables - 10-17-2007 , 01:51 PM



steve wrote:

Quote:
My question is if you can define a temporary variable within a query to >store tablesor fields. (Like the LET clause of LINQ).

The answer is of course! Jump in anywhere and you will see what makes
sense You can start here:
http://beyondsql.blogspot.com/2007/0...variables.html

best,.
www.beyondsql.blogspot.com
Posting only to discuss one's own product is one of the ten early
warning signs of crankery.


Reply With Quote
  #5  
Old   
steve
 
Posts: n/a

Default Re: Query Variables - 10-17-2007 , 10:25 PM



On Oct 17, 11:51 am, Ed Murphy <emurph... (AT) socal (DOT) rr.com> wrote:
Quote:
steve wrote:
My question is if you can define a temporary variable within a query to >store tablesor fields. (Like the LET clause of LINQ).

The answer is of course! Jump in anywhere and you will see what makes
sense You can start here:
http://beyondsql.blogspot.com/2007/0...es-are-typed-v...

best,.
www.beyondsql.blogspot.com

Posting only to discuss one's own product is one of the ten early
warning signs of crankery.
If you had bothered to read the link you'd see it was exactly what the
op was asking for. I guess you can be an sql cop. I'm not so sure
about a detective



Reply With Quote
  #6  
Old   
Ed Murphy
 
Posts: n/a

Default Re: Query Variables - 10-18-2007 , 09:29 PM



steve wrote:

Quote:
On Oct 17, 11:51 am, Ed Murphy <emurph... (AT) socal (DOT) rr.com> wrote:
steve wrote:
My question is if you can define a temporary variable within a query to >store tablesor fields. (Like the LET clause of LINQ).
The answer is of course! Jump in anywhere and you will see what makes
sense You can start here:
http://beyondsql.blogspot.com/2007/0...es-are-typed-v...
best,.
www.beyondsql.blogspot.com
Posting only to discuss one's own product is one of the ten early
warning signs of crankery.

If you had bothered to read the link you'd see it was exactly what the
op was asking for. I guess you can be an sql cop. I'm not so sure
about a detective
Well, this /is/ a SQL group, y'know. The guy is asking whether SQL
has a non-trivial capability, so is quite possibly working on an
existing system that has already undergone a significant chunk of
development in SQL. Responding with "this is easy in <other system>"
is all well and good, but if he's going to have to rewrite everything
under the sun to take advantage of it, then it's a bit useless, innit?

You give lots of examples of code written for your system, but what
does your API look like? Typical end-user programs consist of front-end
screens implemented in something like VB or VC# or ASP.NET, calling out
to SQL on the back end with code along the lines of (pseudocode)

loop over exec_sql("select x, y from z order by x, y", x, y)
// do stuff with x and y
end loop

populate_grid(g, exec_sql("select x, y from z order by x, y"))

exec_sql("exec spMyStoredProcedure")

Do you provide something like this for your product, or is the
developer expected to rewrite all front-end screens in the front-end
component of your system? If the latter, then it's really only
useful to people developing new systems, or at least new sub-systems.

In any case, at least you're not as nuts as the guy in this story:
http://forums.worsethanfailure.com/f...ad/132591.aspx


Reply With Quote
Reply




Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off



Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.