CODEWITHSUNDEEP
sql-serversql-server-2005
chezy525
chezy525

Reputation: 4174

Dynamic inner query

Is there a way to code a dynamic inner query? Basically, I find myself typing something like the following query over and over:

;with tempData as (
   --this inner query is the part that changes, but there's always a timeGMT column.
   select timeGMT, dataCol2, dataCol3
   from tbl1 t1
      join tbl2 t2 on t1.ID=t2.ID
)
select dateadd(ss,d.gmtOffset,t.timeGMT) timeLocal,
   t.*
from tempData t
   join dst d on t.timeGMT between d.sTimeGMT and d.eTimeGMT
where d.zone = 'US-Eastern'

The only thing I can think of is a stored proc with the inner query text as the input for some dynamic sql... However, my understanding of the optimizer (which is, admittedly, limited) says this isn't really a good idea.

Upvotes: 1

Views: 112

Answers (2)

John Pick
John Pick

Reputation: 5650

To answer the OP's follow-on question, a SQL Server 2008 solution would look like this:

First, create permanent definitions:

CREATE TYPE dbo.tempDataType AS TABLE (
    timeGMT DATETIME,
    dataCol2 int,
    dataCol3 int)
GO

CREATE PROCEDURE ComputeDateWithDST
    @tempData tempDataType READONLY
AS
SELECT dateadd(ss,d.gmtOffset,t.timeGMT) timeLocal, t.*
FROM @tempData t
JOIN dst d ON t.timeGMT BETWEEN d.sTimeGMT AND d.eTimeGMT
WHERE d.zone = 'US-Eastern'
GO

Thereafter, whenever you want to plug a subquery (which has now become a separate query, no longer a CTE) into the stored procedure:

DECLARE @tempData tempDataType

INSERT @tempData
-- sample subquery:
SELECT timeGMT, dataCol2, dataCol3
FROM tbl1 t1
JOIN tbl2 t2 ON t1.ID=t2.ID

EXEC ComputeDateWithDST @tempData;
GO

Performance could be an issue because you'd be running separately what used to be a CTE instead of letting SQL Server combine it with the main query to optimize the execution plan.

Upvotes: 0

Phil Helmer
Phil Helmer

Reputation: 1240

From a performance perspective, what you have there is the version on which I would expect the optimizer to do the best job.

If the "outer" part of your example is static and code maintenance overrides performance, I'd look to encapsulating the dateadd result in a table-valued function (TVF). Since the time conversion is very much the common thread in these queries, I would definitely focus on that part of the workload.

For example, your query that can vary would look like this:

select timeGMT, dataCol2, dataCol3, lt.timeLocal
from   tbl1 t1
       join tbl2 t2 on t1.ID = t2.ID
       cross apply dbo.LocalTimeGet(timeGMT, 'US-Eastern') AS lt

Where the TVF dbo.LocalTimeGet contains the logic for dateadd(ss,d.gmtOffset,t.timeGMT) and the lookup of the time zone offset value based on the time zone name. The implementation of that function would look something like:

CREATE FUNCTION dbo.LocalTimeGet (
    @TimeGMT  datetime,
    @TimeZone varchar(20)
)
RETURNS TABLE
AS
RETURN (
    SELECT  DATEADD(ss, d.gmtOffset, @TimeGMT) AS timeLocal
    FROM    dst AS d
    WHERE   d.zone = @TimeZone
);
GO

The upside of this approach is when you upgrade to 2008 or later, there are system functions you could use to make this conversion a lot easier to code and you'll only have to alter the TVF. If your result sets are small, I'd consider a system scalar function (SQL 2008) over a TVF, even if it implements those same system functions. Based on your comment, it sounds like the system functions won't do what you need, but you could still stick with your implementation of a dst table, which is encapsulated in the TVF above.

TVFs can be a performance problem because the optimizer assumes they only return 1 row.

If you need to combine encapsulation and performance, then I'd do the time zone calc in the application code instead. Even though you'd have to apply it to each project that uses it, you would only have to implement it 1x in each project (in the Data Access Layer) and treat it as a common utility library if you'll be using across projects.

Upvotes: 1

Related Questions