June 26, 2013 at 8:04 pm
I'm working on converting some old Sybase DBs to SQL, and am stuck on one query. Here's the original:
/* original
SELECT A.recid,
A.id,
A.procid,
A.pstatus,
B.pname,
B.pdesc,
LEN(pname) AS plen,
CASE
WHEN C.seq IS NULL THEN 0
ELSE 1
END AS DISABLED
FROMlprocs A,
pmaster B,
pmap C
WHERE A.procid = B.procid
AND A.id = @id
AND C.procid =* A.procid
AND C.typeid =* (
SELECT D.typeid
FROM loan D
WHERE D.id = A.id
)
ORDER BY pname
*/
And here's my (weak) attempt
/* my attempt - obviously produces a different query plan
SELECT A.recid,
A.id,
A.procid,
A.pstatus,
B.pname,
B.pdesc,
LEN(pname) AS plen,
CASE
WHEN C.seq IS NULL THEN 0
ELSE 1
END AS DISABLED
FROMlprocs A
JOIN pmaster B
ON A.procid = B.procid
LEFT OUTER JOIN pmap C
ON C.procid = A.procid
WHERE
A.id = @id
AND C.typeid in (
SELECT D.typeid
FROM loan D
WHERE D.id = A.id
)
ORDER BY pname
*/
Please help, thanks!
June 27, 2013 at 1:06 am
CleverSQLUserID (6/26/2013)
- obviously produces a different query plan
The query plan is not the indication that your new-style code is false or correct. Your resultset must be the same with both queries. Your second query looks good to me, but I must admit I'm not familiar with the old-style code.
Will this code produce the same resultset?SELECT A.recid
, A.id
, A.PROCID
, A.pstatus
, B.pname
, B.pdesc
, LEN(pname) AS plen
, CASE
WHEN C.seq IS NULL
THEN 0
ELSE 1
END AS DISABLED
FROM lprocs A
INNER JOIN pmaster B
ON A.PROCID = B.PROCID
LEFT OUTER JOIN pmap C
ON C.PROCID = A.PROCID
AND C.typeid IN (
SELECT D.typeid
FROM loan D
WHERE A.id = D.id
)
WHERE A.id = @id
ORDER BY pname
June 27, 2013 at 8:24 am
IIRC =* is a right join, not a left join. *= is a left join.
SELECT A.recid,
A.id,
A.PROCID,
A.pstatus,
B.pname,
B.pdesc,
LEN(pname) AS plen,
CASE WHEN C.seq IS NULL THEN 0 ELSE 1 END AS DISABLED
FROM lprocs A,
inner join master B on A.PROCID = B.PROCID
right join pmap C on C.PROCID = A.PROCID
and C.typeid = (SELECT D.typeid FROM loan D WHERE D.id = A.id) --be careful here, this subquery could return more than 1 row
WHERE A.id = @id
ORDER BY pname
Be careful with that subquery, the subquery may return more than 1 row.
As a side note, it is a pet peeve of mine to use aliases a,b,c,d. They don't mean anything and I find actually make it more difficult to work with. You have to constantly keep referring to the from section of your query to remember which table is which.
Something like this. It is much easier to know what table any given column belongs to.
SELECT p.recid,
p.id,
p.PROCID,
p.pstatus,
m.pname,
m.pdesc,
LEN(pname) AS plen,
CASE WHEN m.seq IS NULL THEN 0 ELSE 1 END AS DISABLED
FROM lprocs p,
inner join [master] m on p.PROCID = m.PROCID]
inner join loan l on l.id = p.id
right join pmap m on m.PROCID = p.PROCID
and m.typeid = l.typeid
WHERE p.id = @id
ORDER BY pname
_______________________________________________________________
Need help? Help us help you.
Read the article at http://www.sqlservercentral.com/articles/Best+Practices/61537/ for best practices on asking questions.
Need to split a string? Try Jeff Modens splitter http://www.sqlservercentral.com/articles/Tally+Table/72993/.
Cross Tabs and Pivots, Part 1 – Converting Rows to Columns - http://www.sqlservercentral.com/articles/T-SQL/63681/
Cross Tabs and Pivots, Part 2 - Dynamic Cross Tabs - http://www.sqlservercentral.com/articles/Crosstab/65048/
Understanding and Using APPLY (Part 1) - http://www.sqlservercentral.com/articles/APPLY/69953/
Understanding and Using APPLY (Part 2) - http://www.sqlservercentral.com/articles/APPLY/69954/
June 27, 2013 at 8:33 am
Thanks for the assistance. I agree with your take on using a/b/c as aliases, but I was tasked with "get it working, don't get it pretty". I thought that replacing an outer join with an "IN" was risky, but I think it's riskier to replace it with an "=", since, like you said, the query could return more than one result. I'll have to ask the business unit if that's by design, but is there not a way to maintain the join relationship?
Viewing 4 posts - 1 through 3 (of 3 total)
You must be logged in to reply to this topic. Login to reply