Showing posts with label tablea. Show all posts
Showing posts with label tablea. Show all posts

Monday, March 19, 2012

Joining from two different DB

May I know how to issue JOIN statement to join two ID from different DB ?

example:

dbA - tableA - a.ID

dbB- tableB - b.ID

Thanks.

Use DBName..TableName OR DBName.DBO.TableName

For example, SELECT a.SomeColumn FROM a INNER JOIN dbB..b AS bT ON a.ID = bt.ID

|||

The syntax is [server].[database].[schema].[table] for table names, you can reference the table(s) as:

tableA or dbo.tableA or dbA.dbo.tableA or myserver.dbA.dbo.tableA.

If you need to reference a table in a different schema, you must use 2-part (or more) table names. If you want to reference a table that is in a different database, use 3-part (or more). If you want to reference a table on a different server, use 4-part.

Monday, March 12, 2012

Joing tables using more than one field

I have two tables I need to join but there are 2 fields which they
could be joined on.

Using the example Tablles, TableA and TableB below;

TableA
ID1 ID2 Qty
1 Null 4
2 A 5
Null B 6

TableB
ID1 ID2 Qty
Null A 6
3 B 6
4 Null 7
Null C 8

I want to create TableC which will look like this;
ID1 ID2 TableA.Qty Tableb>Qty
1 Null 4 Null
2 A 5 6
3 B 6 6
4 Null Null 7
Null C Null 8

Any ideas?

Regards,
CiarnTry:

select
*
from
TableA a
join
TableB b on b.ID1 = a.ID1 and b.ID2 = a.ID2

--
Tom

----------------
Thomas A. Moreau, BSc, PhD, MCSE, MCDBA
SQL Server MVP
Columnist, SQL Server Professional
Toronto, ON Canada
www.pinpub.com
..
<chudson007@.hotmail.com> wrote in message
news:1142947436.438108.100180@.j33g2000cwa.googlegr oups.com...
I have two tables I need to join but there are 2 fields which they
could be joined on.

Using the example Tablles, TableA and TableB below;

TableA
ID1 ID2 Qty
1 Null 4
2 A 5
Null B 6

TableB
ID1 ID2 Qty
Null A 6
3 B 6
4 Null 7
Null C 8

I want to create TableC which will look like this;
ID1 ID2 TableA.Qty Tableb>Qty
1 Null 4 Null
2 A 5 6
3 B 6 6
4 Null Null 7
Null C Null 8

Any ideas?

Regards,
Ciarn|||select coalesce(a.ID1,b.ID1),
coalesce(a.ID2,b.ID2),
a.Qty,
b.Qty
from TableA a
full outer join TableB b on a.ID1=b.ID1 or a.ID2=b.ID2

Friday, March 9, 2012

Join vs Where performance

Consider the following hypothetical queries:
QUERY A
Select ...
>From TableA TA Join TableB TB
ON TA.Field1 = TB.Field1 AND
TA.Field2 = TB.Field2 AND
TA.Field3 = TB.Field3
Where
TA.Field4 = 'Some Value'
QUERY B
Select ...
>From TableA TA Join TableB TB
ON TA.Field1 = TB.Field1
Where
TA.Field4 = 'Some Value' AND
TA.Field2 = TB.Field2 AND
TA.Field3 = TB.Field3
Notice that the difference is that the Join clause in Query A has more
than one expression to evaluate but in Query B, the Join only has a
single expression and the other expressions have been moved to the
Where clause.
These queries should return the same results but my question is about
performance. What are the best practices regarding Joins vs the Where
clause? Do these queries have significantly differing performance?
Which is preferred and why?
Can someone point me to some articles or books that would help me to
under stand?
ThanksChris,
I don't think you will see any performance differences (generally) between
either method (INNER JOINS). I generally prefer to use JOINs for the join
criteria and WHERE for filtering. Using JOIN can help reduce the number of
cross joins when the WHERE clause is ommitted. Also, ANSI compliance when
using LEFT or RIGHT as opposed to *= or =*.
HTH
Jerry
"Chris Dunaway" <dunawayc@.gmail.com> wrote in message
news:1129744620.635243.276050@.o13g2000cwo.googlegroups.com...
> Consider the following hypothetical queries:
> QUERY A
> Select ...
> ON TA.Field1 = TB.Field1 AND
> TA.Field2 = TB.Field2 AND
> TA.Field3 = TB.Field3
> Where
> TA.Field4 = 'Some Value'
>
> QUERY B
> Select ...
> ON TA.Field1 = TB.Field1
> Where
> TA.Field4 = 'Some Value' AND
> TA.Field2 = TB.Field2 AND
> TA.Field3 = TB.Field3
>
> Notice that the difference is that the Join clause in Query A has more
> than one expression to evaluate but in Query B, the Join only has a
> single expression and the other expressions have been moved to the
> Where clause.
> These queries should return the same results but my question is about
> performance. What are the best practices regarding Joins vs the Where
> clause? Do these queries have significantly differing performance?
> Which is preferred and why?
> Can someone point me to some articles or books that would help me to
> under stand?
> Thanks
>|||hit CTRL + K
run both queries and look if the execution plans are different
http://sqlservercode.blogspot.com/
"Chris Dunaway" wrote:

> Consider the following hypothetical queries:
> QUERY A
> Select ...
> ON TA.Field1 = TB.Field1 AND
> TA.Field2 = TB.Field2 AND
> TA.Field3 = TB.Field3
> Where
> TA.Field4 = 'Some Value'
>
> QUERY B
> Select ...
> ON TA.Field1 = TB.Field1
> Where
> TA.Field4 = 'Some Value' AND
> TA.Field2 = TB.Field2 AND
> TA.Field3 = TB.Field3
>
> Notice that the difference is that the Join clause in Query A has more
> than one expression to evaluate but in Query B, the Join only has a
> single expression and the other expressions have been moved to the
> Where clause.
> These queries should return the same results but my question is about
> performance. What are the best practices regarding Joins vs the Where
> clause? Do these queries have significantly differing performance?
> Which is preferred and why?
> Can someone point me to some articles or books that would help me to
> under stand?
> Thanks
>|||I have done that and, being inexperienced in T-SQL, I do not fully
understand what the execution plans are telling me. My question was
more general than specific. The hypothetical queries I provided may
perform equivalently. I am more interested in best practices. In
general, when joining two table using JOIN, is it advantageous to have
more than one join expression? Also, would you ever put a constant
value in a join expression like this:
Select ...
>From TableA TA Join TableB TB
ON TA.Field1 = TB.Field1 AND
TA.Field2 = TB.Field2 AND
TA.Field3 = TB.Field3 AND
TA.Field5 = 'const expression'
Where
TA.Field4 = 'Some Value'
I want to make my queries as fast as possible (don't we all?) and I
want to make sure that I use practices that others have found to
reliably produce better results.
Can you recommend any books that will help me to learn more about how
Queries are optimized in SQL Server?
Thanks again.|||Inside Microsoft SQL Server 2000
by Kalen Delaney
http://www.amazon.com/exec/obidos/A...link%5Fcode=xm2
One of the best books
"Chris Dunaway" wrote:

> I have done that and, being inexperienced in T-SQL, I do not fully
> understand what the execution plans are telling me. My question was
> more general than specific. The hypothetical queries I provided may
> perform equivalently. I am more interested in best practices. In
> general, when joining two table using JOIN, is it advantageous to have
> more than one join expression? Also, would you ever put a constant
> value in a join expression like this:
> Select ...
> ON TA.Field1 = TB.Field1 AND
> TA.Field2 = TB.Field2 AND
> TA.Field3 = TB.Field3 AND
> TA.Field5 = 'const expression'
> Where
> TA.Field4 = 'Some Value'
> I want to make my queries as fast as possible (don't we all?) and I
> want to make sure that I use practices that others have found to
> reliably produce better results.
> Can you recommend any books that will help me to learn more about how
> Queries are optimized in SQL Server?
> Thanks again.
>|||IMO, your best performance will be realized if have built the appropriate
indexes on your tables.
I generally stay away from compound keys unless they are used specifically
for sorting.
When MS bought Fox Software they incorporated some of the technology known
then as Rushmore into SQL Server. Rushmore relied almost exclusively on
index schemes for speed.
If you have indexes build on the fields that will be most commonly used in
queries and join conditions, you will see better performance than if the
indexes did not exist. However, if the tables are small, you may not see
any improvement at all.
HTH,
-Steve-|||Hi Chris,
There is no significant performance difference between the two. You can
compare the query plans to check if they are the same (no knowledge of
query plans is required for that). If the are the same, then execution
(and performance) will be the same.
You ask for best practices. To me, the best way to write a query is to
make the query easy to read, easy to maintain, but still resulting in
efficient execution. In that order (performance last).
IMO, the best practice is to only specify the joining columns in the ON
clause, and all filtering expressions in the WHERE clause. Typically,
this means that you only mention the foreign key column(s) in the ON
clause.
Of course, this only applies to inner joins. For outer joins the
functional difference will determine which expressions are placed in the
ON clause and which in the WHERE clause.
Gert-Jan
Chris Dunaway wrote:
> Consider the following hypothetical queries:
> QUERY A
> Select ...
> ON TA.Field1 = TB.Field1 AND
> TA.Field2 = TB.Field2 AND
> TA.Field3 = TB.Field3
> Where
> TA.Field4 = 'Some Value'
> QUERY B
> Select ...
> ON TA.Field1 = TB.Field1
> Where
> TA.Field4 = 'Some Value' AND
> TA.Field2 = TB.Field2 AND
> TA.Field3 = TB.Field3
> Notice that the difference is that the Join clause in Query A has more
> than one expression to evaluate but in Query B, the Join only has a
> single expression and the other expressions have been moved to the
> Where clause.
> These queries should return the same results but my question is about
> performance. What are the best practices regarding Joins vs the Where
> clause? Do these queries have significantly differing performance?
> Which is preferred and why?
> Can someone point me to some articles or books that would help me to
> under stand?
> Thanks

Monday, February 20, 2012

join or subselect ??

Not sure if this is the right group to post this to but.

This is the current query that I have.

select tableA.id,tableB.artist,tableB.image,from tableA,tableB where
tableA.image = tableB.image AND tableB.price >0 AND tableB.price < 20
order by tableB.price DESC'

What I need is, for each row returned I need information from a third
and fourth table. tableC, and tableD.

tableC has information ( the tableA.id = tableC.eventId) that I need to
obtain tableC.accountId = tableD.accountId in order do select the
the binding information in tableD between a Vendor(name,address..etc..)
and tableB.image

Any help would be greatly appreciated.If I'm reading you correctly, you should be able to do this pretty easily.
In the SELECT statement, list all the fields from each table that you want
to see. In the FROM statement list the tables. In the WHERE statement list
all the parameters and relationships. So:

SELECT
tableA.fields
tableB.fields
tableC.fields
tableD.fields
FROM
TableA
TableB
TableC
TableD
WHERE
tableA.image = tableB.image AND
tablea.id = tableC.eventID AND
talbeC.accountID = tableD.accountID AND
tableB.price >0 AND
tableB.price < 20
ORDER by tableB.price DESC

"kjc" <ksitron@.elp.rr.com> wrote in message
news:OnIXc.52730$xi6.21027@.fe2.texas.rr.com...
> Not sure if this is the right group to post this to but.
> This is the current query that I have.
> select tableA.id,tableB.artist,tableB.image,from tableA,tableB where
> tableA.image = tableB.image AND tableB.price >0 AND tableB.price < 20
> order by tableB.price DESC'
> What I need is, for each row returned I need information from a third
> and fourth table. tableC, and tableD.
>
> tableC has information ( the tableA.id = tableC.eventId) that I need to
> obtain tableC.accountId = tableD.accountId in order do select the
> the binding information in tableD between a Vendor(name,address..etc..)
> and tableB.image
> Any help would be greatly appreciated.|||[Top posting is annoying and confusing. Rearranging ...]

"Big Time" <big-time-grizz@.remove-for-spam-hotmail.com> wrote in
news:cgo06l$10ga$1@.lettuce.bcit.ca:

> "kjc" <ksitron@.elp.rr.com> wrote in message
> news:OnIXc.52730$xi6.21027@.fe2.texas.rr.com...
>> Not sure if this is the right group to post this to but.
>>
>> This is the current query that I have.
>>
>> select tableA.id,tableB.artist,tableB.image,from tableA,tableB where
>> tableA.image = tableB.image AND tableB.price >0 AND tableB.price < 20
>> order by tableB.price DESC'
>>
>> What I need is, for each row returned I need information from a third
>> and fourth table. tableC, and tableD.
>>
>>
>> tableC has information ( the tableA.id = tableC.eventId) that I need
>> to obtain tableC.accountId = tableD.accountId in order do select the
>> the binding information in tableD between a
>> Vendor(name,address..etc..) and tableB.image
>>
>> Any help would be greatly appreciated.
>
> If I'm reading you correctly, you should be able to do this pretty
> easily. In the SELECT statement, list all the fields from each table
> that you want to see. In the FROM statement list the tables. In the
> WHERE statement list all the parameters and relationships. So:
> SELECT
> tableA.fields
> tableB.fields
> tableC.fields
> tableD.fields
> FROM
> TableA
> TableB
> TableC
> TableD
> WHERE
> tableA.image = tableB.image AND
> tablea.id = tableC.eventID AND
> talbeC.accountID = tableD.accountID AND
> tableB.price >0 AND
> tableB.price < 20
> ORDER by tableB.price DESC

This will indeed work fine, and the optimizer should have no problem
(given sufficient foreign key constraints and indexing) rewriting it to
run with maximum efficiency. However, future programmers may thank you
if you separate the join relationships from the filtering clauses:

SELECT
tableA.fields,
tableB.fields,
tableC.fields,
tableD.fields
FROM
tableA
INNER JOIN tableB on tableA.image = tableB.image
INNER JOIN tableC on tableA.id = tableC.eventID
INNER JOIN tableD on tableC.accountID = tableD.accountID
WHERE
tableB.price > 0 AND tableB.price < 20

Join on subquery with distinct?

Can someone give me some reasonable explanation why these two queries are performing dramatically different:

First (slow):

select
tableA.column1,
tableA.column2
from
tableA join (select distinct col1,col2,col3 from myView) vw
on vw.col1=tableA.col1 and vw.col2=tableA.col2 and vw.col3=tableA.col3

Second (fast):

create table #tempTable (col1 varchar(200),col2 int,col3 varchar(200))

insert into #tempTable
select distinct col1,col2,col3 from myView

select

tableA.column1,

tableA.column2

from

tableA join #tempTable vw

on vw.col1=tableA.col1 and vw.col2=tableA.col2 and vw.col3=tableA.col3

SQL Server 2005 Express
Win2K3 Server

Regards,
Marko Simic

Marko:

I can't really mock this without knowing how the view is structured. It is not possible to mock a query plan that involves a view without knowing the components of the view. Can you give details of the makeup of the view?


Dave

|||

Can you post the plan for your queries, such as:

set showplan_text on
--set statistics profile on
go

--your query--


go
--set statistics profile off
set showplan_text off

The showplan one gives you estimated, the profile one gives you actual plan. That will be very helpful in this.

|||

When I executed queries (for generating estimated and actual plans), suddenly problematic one executed much faster.
Most probably, problem was about server's hardware performance, like insufficient RAM, at the moment of query execution.
My assumption is based on the fact that problematic query is using subquery, which by many views, is using more memory then query with temp table.

Anyway, I am sending you a link to XLS file with all statistics (of query with subquery) you asked, in case that something else could cause strange behavior and can be seen from this.

http://139.142.50.130/test/statistics.xls

Thank you for your efforts

|||

Without both to compare it is really impossible to say too confidently, but there are a couple of really large looking table scans (Clustered Index Scan = ordered table scan) followed by a hash match join. This kind of operation can be greatly affected by hardware performance/contention, as the hash match executes faster with more ram.

Comparing the plans might shed some light on it, but if it runs adequately now... :)

|||The optimiser will expand out queries like the first one. Just one of those annoying things about it. You could improve the speed by putting changing it to "select top (999999) distinct col1, col2, col3 from myView", because that will force the server to materialise the table first. Any number will do, so long as it's larger than the number of rows you expect to get out (otherwise you'll lose rows).

Which effectively is the same as populating a temporary table. :)

Rob|||

First of all, thank you all for your replies.
Rob, will you please tell me, what did you mean by "materialise table".
Did you mean that database would move view from memory to hard drive?
And, if that is true, would db engine make that table within tempdb space (as temp tables are) or in original database space?

|||When I say 'materialise', I just mean that the engine will create the table in memory and then join the other tables to it. It won't move it from memory to the hard drive - it will stay in RAM.

Rob|||

ok.Thanks. Then it works as I expected.

|||Ah, great. Glad to help. Can you mark it as an answer please? I know MS are keen for this to happen on all threads.|||With pleasure :) Done|||:) Cheers

join on column with different data types

Hi.
I have a query where a single column is used as join key.
In TableA the column is nvarchar and in TableB it is varchar.
TableB has a clustered index on that column but the join will do a full
table scan
on TableB.
When I convert the coresponding column in TableA to varchar the query use
the index.
The join query will not do an implicit convert between varchar and
nvarchar.
Perhaps as designed.
Where can I find documentation on this issue.
I have been searching books online and Googles but haven't found it.
Sqlserver 2000 or 7.0
--
/dg
----
Dan van Ginhoven
SchlumbergerSema AB
S-412 97 GÖTEBORG Sweden
Phone +46 317 51 44 13
Mob/Cell +46 708 51 44 13convert(varchar(10, column_tableA) = column_tableB
"Dan van Ginhoven" <nospam@.got.sema.se> wrote in message
news:uwiH8IuPDHA.2480@.tk2msftngp13.phx.gbl...
> Hi.
> I have a query where a single column is used as join key.
> In TableA the column is nvarchar and in TableB it is varchar.
> TableB has a clustered index on that column but the join will do a full
> table scan
> on TableB.
> When I convert the coresponding column in TableA to varchar the query use
> the index.
> The join query will not do an implicit convert between varchar and
> nvarchar.
> Perhaps as designed.
> Where can I find documentation on this issue.
> I have been searching books online and Googles but haven't found it.
> Sqlserver 2000 or 7.0
> --
> /dg
> ----
> Dan van Ginhoven
> SchlumbergerSema AB
> S-412 97 GÖTEBORG Sweden
> Phone +46 317 51 44 13
> Mob/Cell +46 708 51 44 13
>|||There is a chart which shows which data types are implicitly or explicitly
convertable in books on line search for convert... The chart indicates that
SQL can implicitly convert between nchar/nvarchar and char/varchar
"Dan van Ginhoven" <nospam@.got.sema.se> wrote in message
news:uwiH8IuPDHA.2480@.tk2msftngp13.phx.gbl...
> Hi.
> I have a query where a single column is used as join key.
> In TableA the column is nvarchar and in TableB it is varchar.
> TableB has a clustered index on that column but the join will do a full
> table scan
> on TableB.
> When I convert the coresponding column in TableA to varchar the query use
> the index.
> The join query will not do an implicit convert between varchar and
> nvarchar.
> Perhaps as designed.
> Where can I find documentation on this issue.
> I have been searching books online and Googles but haven't found it.
> Sqlserver 2000 or 7.0
> --
> /dg
> ----
> Dan van Ginhoven
> SchlumbergerSema AB
> S-412 97 GÖTEBORG Sweden
> Phone +46 317 51 44 13
> Mob/Cell +46 708 51 44 13
>|||Hi Wayne!
Yes I have seen the chart. It surprises me a bit that the query didn't use
the index.
It may be bug.
I´m looking for a text that describes in what situations the Query Planner
will not use an
index, but will do a full table scan. I think I have seen it once.
One example is when a query contains <column> like '%value%'
it won´t use an index on that column to solve the query.
/dg|||> Yes I have seen the chart. It surprises me a bit that the query didn't use
> the index.
> It may be bug.
Nope, it is how SQL Server works. Although you don't have to write any code
for an implicit conversion SQL Server still converts one datatype to another
when it creates the execution plan. If you run the following code in Query
Analyzer and look at the execution plan you will see that #B.B is converted
before the two tables are joined:
CREATE TABLE #A (A nvarchar(20))
GO
CREATE TABLE #B (B varchar(20))
GO
SELECT * FROM #A
INNER JOIN #B
ON #A.A = #B.B
GO
DROP TABLE #A, #B
GO
Why is #B.B converted and not #A.A? That is determined by the Data Type
Precedence. varchar has a lower Data Type Precedence than nvarchar, so
varchar gets converted. (You can find the complete list of the data type
precedence in Books Online under Data Type Precedence).
Because #B.B is used in a function (when it is converted), the Query
Optimizer can't use any indexes on the column and has to use a table scan.
As you saw when the other (nvarchar) column in the join is explicitly
converted, the varchar column won't be implicitly converted and the index on
the varchar column can be used.
About a text: Kalen Delaney has written a series of articles for SQL Server
Magazine (www.sqlmag.com) about which search conditions can make use of
indexes and which don't, and there is also a bit about it in her book Inside
SQL Server 2000.
--
Jacco Schalkwijk MCDBA, MCSD, MCSE
Database Administrator
Eurostop Ltd.
"Dan van Ginhoven" <nospam@.got.sema.se> wrote in message
news:uPHxWevPDHA.1720@.TK2MSFTNGP11.phx.gbl...
> Hi Wayne!
> Yes I have seen the chart. It surprises me a bit that the query didn't use
> the index.
> It may be bug.
> I´m looking for a text that describes in what situations the Query
Planner
> will not use an
> index, but will do a full table scan. I think I have seen it once.
> One example is when a query contains <column> like '%value%'
> it won´t use an index on that column to solve the query.
> /dg
>