| Groups | Blog | Home |
sql server programming : performance : successive queries versus join
a stored procedure to retrieve a single row .... @PrimaryKeyFieldValue is sp input parameter method 1 : select @ForeignKeyFieldValue from Table1 where T1.PrimaryKeyFieldName = @PrimaryKeyFieldValue select * from Table2 where PrimaryKeyFieldName = @ForeignKeyFieldValue method 2 : select * from Table2 T2 inner join Table1 T1 where T2.PrimaryKeyFieldName = T1.ForeignKeyFieldName and T1.PrimaryKeyFieldName = @PrimaryKeyFieldValue
hi Damien and thanks for the response.
very interesting stuff. so, extrapolating from this example, unless a sp locks the tables it's working with, or wraps its code in an explicit transaction, there is no way to stop the sql-svr engine from multitasking execution of t-sql lines in SPs run under different connections ... ? [quoted text, click to view] "Damien Laffan" <iGetEnoughSpamAlreadyThankyou@nospam.com> wrote in message news:Oksy4r57DHA.3112@tk2msftngp13.phx.gbl... You may wish to consider that there is no guarantee that the row in table1 is not deleted between query 1 and 2... (Unless you wrap the whole lot inside an explicit transaction, I believe) By joining you get all the data that matches your criteria at the point in time the query is executed, without the hassle of transient variables etc... Regards, Damien. [quoted text, click to view] "John A Grandy" <johnagrandy-at-yahoo-dot-com> wrote in message i'm sure the following has been extensively benchmarked ...news:#wFvob57DHA.1636@TK2MSFTNGP12.phx.gbl... a stored procedure to retrieve a single row .... @PrimaryKeyFieldValue is sp input parameter method 1 : select @ForeignKeyFieldValue from Table1 where T1.PrimaryKeyFieldName = @PrimaryKeyFieldValue select * from Table2 where PrimaryKeyFieldName = @ForeignKeyFieldValue method 2 : select * from Table2 T2 inner join Table1 T1 where T2.PrimaryKeyFieldName = T1.ForeignKeyFieldName and T1.PrimaryKeyFieldName = @PrimaryKeyFieldValue
John
In the second query you are using inavlid syntax to join the tables. You cannot specify WHERE clause after JOIN condition ,instead use ON table.pk=table1.fk [quoted text, click to view] "John A Grandy" <johnagrandy-at-yahoo-dot-com> wrote in message news:eYv#J357DHA.1112@tk2msftngp13.phx.gbl... > hi Damien and thanks for the response. > > very interesting stuff. so, extrapolating from this example, unless a sp > locks the tables it's working with, or wraps its code in an explicit > transaction, there is no way to stop the sql-svr engine from multitasking > execution of t-sql lines in SPs run under different connections ... ? > > > "Damien Laffan" <iGetEnoughSpamAlreadyThankyou@nospam.com> wrote in message > news:Oksy4r57DHA.3112@tk2msftngp13.phx.gbl... > > You may wish to consider that there is no guarantee that the row in table1 > is not deleted between query 1 and 2... (Unless you wrap the whole lot > inside an explicit transaction, I believe) > > By joining you get all the data that matches your criteria at the point in > time the query is executed, without the hassle of transient variables etc... > > > Regards, > Damien. > > > "John A Grandy" <johnagrandy-at-yahoo-dot-com> wrote in message > news:#wFvob57DHA.1636@TK2MSFTNGP12.phx.gbl... > i'm sure the following has been extensively benchmarked ... > > a stored procedure to retrieve a single row .... @PrimaryKeyFieldValue is sp > input parameter > > method 1 : > > select @ForeignKeyFieldValue from Table1 where T1.PrimaryKeyFieldName = > @PrimaryKeyFieldValue > select * from Table2 where PrimaryKeyFieldName = @ForeignKeyFieldValue > > method 2 : > > select * from Table2 T2 inner join Table1 T1 where T2.PrimaryKeyFieldName = > T1.ForeignKeyFieldName and T1.PrimaryKeyFieldName = @PrimaryKeyFieldValue > > > > > > >
You may wish to consider that there is no guarantee that the row in = table1 is not deleted between query 1 and 2... (Unless you wrap the = whole lot inside an explicit transaction, I believe) By joining you get all the data that matches your criteria at the point = in time the query is executed, without the hassle of transient variables = etc... Regards, Damien. [quoted text, click to view] "John A Grandy" <johnagrandy-at-yahoo-dot-com> wrote in message = i'm sure the following has been extensively benchmarked ...news:#wFvob57DHA.1636@TK2MSFTNGP12.phx.gbl... a stored procedure to retrieve a single row .... @PrimaryKeyFieldValue = is sp input parameter method 1 : select @ForeignKeyFieldValue from Table1 where T1.PrimaryKeyFieldName = =3D @PrimaryKeyFieldValue select * from Table2 where PrimaryKeyFieldName =3D @ForeignKeyFieldValue method 2 : select * from Table2 T2 inner join Table1 T1 where = T2.PrimaryKeyFieldName =3D T1.ForeignKeyFieldName and T1.PrimaryKeyFieldName =3D = @PrimaryKeyFieldValue
I am definitely not the best person to comment on the internal locking = mechanisms of MSSQL... Have a read of Books Online, the "Accessing and = Changing Data" chapter will probably be useful for you. Joins are an integral part of SQL, and I don't think that avoiding them = will provide many (or any) benefits. Just my opinion... Regards, Damien. [quoted text, click to view] "John A Grandy" <johnagrandy-at-yahoo-dot-com> wrote in message = hi Damien and thanks for the response.news:eYv#J357DHA.1112@tk2msftngp13.phx.gbl... very interesting stuff. so, extrapolating from this example, unless a = sp locks the tables it's working with, or wraps its code in an explicit transaction, there is no way to stop the sql-svr engine from = multitasking execution of t-sql lines in SPs run under different connections ... ? "Damien Laffan" <iGetEnoughSpamAlreadyThankyou@nospam.com> wrote in = message news:Oksy4r57DHA.3112@tk2msftngp13.phx.gbl... You may wish to consider that there is no guarantee that the row in = table1 is not deleted between query 1 and 2... (Unless you wrap the whole lot inside an explicit transaction, I believe) By joining you get all the data that matches your criteria at the point = in time the query is executed, without the hassle of transient variables = etc... Regards, Damien. [quoted text, click to view] "John A Grandy" <johnagrandy-at-yahoo-dot-com> wrote in message i'm sure the following has been extensively benchmarked ...news:#wFvob57DHA.1636@TK2MSFTNGP12.phx.gbl... a stored procedure to retrieve a single row .... @PrimaryKeyFieldValue = is sp input parameter method 1 : select @ForeignKeyFieldValue from Table1 where T1.PrimaryKeyFieldName = =3D @PrimaryKeyFieldValue select * from Table2 where PrimaryKeyFieldName =3D @ForeignKeyFieldValue method 2 : select * from Table2 T2 inner join Table1 T1 where = T2.PrimaryKeyFieldName =3D T1.ForeignKeyFieldName and T1.PrimaryKeyFieldName =3D = @PrimaryKeyFieldValue
I noticed my typo after I posted ... unfortunately no way for an autor to
edit his newsgroup posts. [quoted text, click to view] "Uri Dimant" <urid@iscar.co.il> wrote in message news:%23DYSdF67DHA.1804@TK2MSFTNGP12.phx.gbl... > John > In the second query you are using inavlid syntax to join the tables. You > cannot specify WHERE clause after JOIN condition ,instead use ON > table.pk=table1.fk > > > > "John A Grandy" <johnagrandy-at-yahoo-dot-com> wrote in message > news:eYv#J357DHA.1112@tk2msftngp13.phx.gbl... > > hi Damien and thanks for the response. > > > > very interesting stuff. so, extrapolating from this example, unless a sp > > locks the tables it's working with, or wraps its code in an explicit > > transaction, there is no way to stop the sql-svr engine from multitasking > > execution of t-sql lines in SPs run under different connections ... ? > > > > > > "Damien Laffan" <iGetEnoughSpamAlreadyThankyou@nospam.com> wrote in > message > > news:Oksy4r57DHA.3112@tk2msftngp13.phx.gbl... > > > > You may wish to consider that there is no guarantee that the row in table1 > > is not deleted between query 1 and 2... (Unless you wrap the whole lot > > inside an explicit transaction, I believe) > > > > By joining you get all the data that matches your criteria at the point in > > time the query is executed, without the hassle of transient variables > etc... > > > > > > Regards, > > Damien. > > > > > > "John A Grandy" <johnagrandy-at-yahoo-dot-com> wrote in message > > news:#wFvob57DHA.1636@TK2MSFTNGP12.phx.gbl... > > i'm sure the following has been extensively benchmarked ... > > > > a stored procedure to retrieve a single row .... @PrimaryKeyFieldValue is > sp > > input parameter > > > > method 1 : > > > > select @ForeignKeyFieldValue from Table1 where T1.PrimaryKeyFieldName = > > @PrimaryKeyFieldValue > > select * from Table2 where PrimaryKeyFieldName = @ForeignKeyFieldValue > > > > method 2 : > > > > select * from Table2 T2 inner join Table1 T1 where T2.PrimaryKeyFieldName > = > > T1.ForeignKeyFieldName and T1.PrimaryKeyFieldName = @PrimaryKeyFieldValue > > > > > > > > > > > > > > > >
Don't see what you're looking for? Try a search.
|
January 2003
March 2003
April 2003
May 2003
June 2003
July 2003
August 2003
September 2003
October 2003
November 2003
December 2003
January 2004
February 2004
March 2004
April 2004
May 2004
June 2004
July 2004
August 2004
September 2004
October 2004
November 2004
December 2004
January 2005
February 2005
March 2005
April 2005
May 2005
June 2005
July 2005
August 2005
September 2005
October 2005
November 2005
December 2005
January 2006
February 2006
March 2006
April 2006
May 2006
June 2006
July 2006
August 2006
September 2006
October 2006
November 2006
December 2006
January 2007
February 2007
March 2007
April 2007
May 2007
June 2007
July 2007
August 2007
September 2007
October 2007
November 2007
April 2008
August 2008
| home · blog · groups | Questions? Comments? Contact the dn |