I'm rewriting a bunch of old, badly written Oracle queries against a new(-er) Sql Server 2008 environment. They use old-school Oracle join syntax like
select <whatever>
from Table1, Table2, Table3
where Table1.T1ID = Table2.T2ID -- old Oracle inner join
and Table2.T3ID = Table3.T3ID (+) -- old Oracle left join (I think)
Except a lot more complicated. There's a lot of mixed joins and a lot of nesting and a lot of views piled on views going on in these things. It's not pretty. The data is disparate between the two servers too, making testing a chore.
I figured the easiest way to replicate would be to make the queries look as similar as possible in Sql Server (ie, using the same style of join), and then do a massive clean-up job after once I'm confident they're both definitely doing the same thing & I don't have a join in the wrong place somewhere (and yes, I have compatibility mode temporarily set to support old joins).
I know the 'old' syntax for an inner join in T-Sql is
select <whatever>
from T1, T2
where T1.ID = T2.ID
but what is the 'old' syntax for a left outer join or a right outer join?
From the documentation on TechNet (on SQL Server 2000, so be aware this might not be supported any more!), you need to use *= instead of the (+) as Oracle does:
select <whatever>
from T1, T2
where T1.ID *= T2.ID
Related
I'm new to SQL and need a push in the right direction.
I currently have a working SQL query accessing 3 tables in a database, and I need to add a JOIN using a 4th table, but the syntax escapes me. To simplify, what I have now is:
SELECT
t1_col1, t1_col2, t2_col1, t2_col2, t3_col1
FROM
table1, table2, table3
WHERE
{some conditions}
ORDER BY
t1_col1 ASC;
What I need to do is to add a LEFT OUTER JOIN selecting 2 columns from table4 and have ON t1_field1 = t4_field1, but whatever I try, I'm getting syntax errors all over the place. I don't seem to understand the correct syntax.
I tried
SELECT *
FROM table1
LEFT OUTER JOIN table2;
which has no errors, but as soon as I start SELECTing columns and adding conditions, I get stuck.
I would greatly appreciate any assistance with this.
You do not specify the join criteria. Those would be in your WHERE clause under "some conditions". So, I will make up so that I can show syntax. The syntax you show is often termed "old". It has been discouraged for 15 years or more in the SQL Server documentation. Microsoft consistently threatens to stop recognizing the syntax. But, apparently they have not followed through on that threat.
The syntax errors you are getting occur because you are mixing the old style joins (comma separated with WHERE clause) with the new style (LEFT OUTER JOIN) with ON clauses.
Your existing query should be changed to something like this. The tables are aliased because it makes it easier to read and is customary. I just made up the JOIN criteria.
SELECT t1_col1, t1_col2, t2_col1, t2_col2, t3_col1
FROM table1 t1
INNER JOIN table2 t2 ON t2.one_ID = t1.one_ID
INNER JOIN table3 t3 ON t3.two_ID = t2.two_ID
LEFT OUTER JOIN table4 t4 ON t4.three_ID = t3.three_ID
I hope that helps with "a push in the right direction."
You may also want to read this post that explains the different ways to join tables in a query. What's the difference between INNER JOIN, LEFT JOIN, RIGHT JOIN and FULL JOIN?
Also for the record the "OLD STYLE" of joining tables (NOT RECOMMENDED) would look like this (but do NOT do this - it is a horrible way to write SQL). And it does not work for left outer joins. Get familiar with using the ...JOIN...ON... syntax:
SELECT t1_col1, t1_col2, t2_col1, t2_col2, t3_col1
FROM table1 t1, table2 t2, table3 t3
LEFT OUTER JOIN table4 t4 ON t4.three_ID = t3.three_ID
WHERE
t2.one_ID = t1.one_ID
AND t3.two_ID = t2.two_ID
This question already has answers here:
Explicit vs implicit SQL joins
(12 answers)
Closed 7 years ago.
I am on a project where much of the queries are performed by including multiple tables in the FROM clause. I know this is legal, but I have always used explicit JOINs instead.
For example, two tables (using SQL Server DDL)
CREATE TABLE Manufacturers(
ManufacturerID INT IDENTITY(1,1) PRIMARY KEY NOT NULL,
Name varchar(100))
CREATE TABLE Cars (
ModelID INT IDENTITY(1,1) PRIMARY KEY NOT NULL,
ManufacturerID INT CONSTRAINT FOREIGN KEY FK_Manufacturer REFERENCES Manufacturers(ManufacturerID),
ModelName VARCHAR(100))
If I want to find the models for GM, I could do either:
SELECT ModelName FROM Cars c, Manufacturers m WHERE c.ManufacturerID=m.ManufacturerID AND m.Name='General Motors'
or
SELECT ModelName FROM Cars c INNER JOIN Manufacturers m ON c.ManufacturerID=m.ManufacturerID WHERE m.Name='General Motors'
My question is this: does one form perform better than the other? Aside from how the tables are defined in Oracle vs SQL Server, does one form of join work better than the other in Oracle or SQL Server? What if you include more tables, say 3 or 4? Does that change the performance characteristics, assuming the queries are constructed to return an equivalent record set?
My question is this: does one form perform better than the other?
They should not. You can check your execution plans to be certain, but every RDBMS I've worked with generates the same plans for comma (ANSI-89) joins as they do for ANSI-92 explicit joins. (Note that comma joins didn't stop being ANSI SQL, it's just that ANSI-92 is where the explicit syntax first appeared.)
Aside from how the tables are defined in Oracle vs SQL Server, does one form of join work better than the other in Oracle or SQL Server?
As far as the server is concerned, no.
What if you include more tables, say 3 or 4? Does that change the performance characteristics, assuming the queries are constructed to return an equivalent record set?
It's possible. With comma joins, I'm not sure it's possible to control the JOIN order with parentheses like you can with explicit joins:
SELECT *
FROM Table1 t1
INNER JOIN (
Table2 t2
INNER JOIN Table3 t3
t2.id = t3.id)
ON t1.id = t2.id
This can affect overall query performance (for better or worse). I'm not sure how to accomplish the same level of control with comma joins, but I've never fully learned comma join syntax. I don't know if you can say Table1 t1, (Table2 t2, Table3 t3), but I don't believe you can. I think you'd have to use subqueries to do that.
The primary advantages of explicit joins are:
Easier to read. It makes it very clear which conditions are used with which join. You won't ever see Table1 t1, Table2 t2, Table3 t3 and then have to dig into the WHERE clause to figure out if one of those joins is an outer join. It also means the WHERE clause isn't stuffed full of all these join conditions you know you don't care about changing when you modify a query.
Easier to use outer joins. In the case of outer joins, you can even specify literal filter values in the outer table without having to handle nulls from the outer join.
Easier to reuse existing joins. If you just want to query from the same relations, you can just grab the FROM clause. You don't have to worry about what bits from the WHERE clause you want and what bits you don't.
Identical syntax across RDBMSs. When you spend all day switching between Oracle and SQL Server, the last thing you want to worry about is confusing + and *= to get your outer joins right.
All of the above make the explicit join syntax more maintainable, which is a very important factor for software.
Our application allows the user to either (1) access our database in SQLite format stored on the local machine, or (2) access our database using SQL server on a server on the same network. For the purposes of this question it's an either-one-or-the-other setup choice.
I was testing both of these setups to check that everything was in order.
I am running a query that in essence is as follows:
INSERT INTO [#Temp_main]
SELECT T1.ID, T2.ID
FROM [#Temp_other] T1
LEFT OUTER JOIN [Table_with_lots_of_data] T2 ON ((T2.ID LIKE T1.ID+'%')
(For the SQLite version of this query, the concatenation operator is '||', which I learnt yesterday from Stackoverflow, thanks!).
So #Temp_other has only the first few chars of the ID, which get matched to the ID column in Table_with_lots_of_data, and the results are saved in #Temp_main.
It all works very well, but the SQLite version of the query is considerably slower than when querying SQL server. Bearing in mind also that the SQL server version also has the additional delay (I presume) of running over the local network, whereas the SQLite database is on the same machine.
I'm not sure if this is to be expected or not? Any help/advice/confirmation would be appreciated.
We are using SQL Server Express 2014. The information in Table_with_lots_of_data is exactly the same on both the SQLite and SQL server versions of our test. It contains approximately 150 000 rows, with 25 columns.
In SQLite, a LIKE with a non-constant second operator cannot be optimized.
If you do not need the case insensitivity, and know the structure of the IDs, you can use something like this, which will able to use an index on T2.ID (in both databases):
SELECT T1.ID, T2.ID
FROM [...] T1
LEFT JOIN [...] T2 ON T2.ID BETWEEN T1.ID AND T1.ID || 'zzzzz'
THe below 2 queries performs the same operation, but wondering which would be the fastest and most preferable?
NUM is the primary key on table1 & table2...
select *
from table1 tb1,
table2 tb2
where tb1.num = tb2.num
select *
from table1 tb1
inner join
table2 tb2
on tb1.num = tb2.num
They are the same query. The first is an older alternate syntax, but they both mean do an inner join.
You should avoid using the older syntax. It's not just readability, but as you build more complex queries, there are things that you simply can't do with the old syntax. Additionally, the old syntax is going through a slow process of being phased out, with the equivalent outer join syntax marked as deprecated in most products, and iirc dropped already in at least one.
The 2 SQL statements are equivalent. You can look at the execution plan to confirm. As a rule, given 2 SQL statements which affect/return the same rows in the same way, the server is free to execute them the same way.
They're equivalent queries - both are inner joins, but the first uses an older, implicit join syntax. Your database should execute them in exactly the same way.
If you're unsure, you could always use the SQL Management Studio to view and compare the execution plans of both queries.
The first example is what I have seen referred to as an Oracle Join. As mentioned already there appears to be little performance difference. I prefer the second example from a readability standpoint because it separates join conditions from filter conditions.
I am trying to understand how JOINS work on SQL Server 2000 and 2005 SPECIFICALLY.
In general, I understand how inner joins, left joins and right joins work.
However, all the articles that I've read, explain it with examples, but are not specific to any RDBMS. So now I am confused to the different types of joins, which are just synonyms of other joins, and which are actually different.
For e.g.,
Is LEFT OUTER JOIN the same as LEFT JOIN?
Is RIGHT OUTER JOIN the same as RIGHT JOIN?
Does SQL Server support FULL OUTER JOIN, CROSS JOIN? What are the different types of joins, and their synonyms. All these keywords are confusing me.
Yes, SQL Server supports FULL OUTER JOIN and CROSS JOIN.
And yes again, LEFT JOIN is a synonym for LEFT OUTER JOIN. The same applies to RIGHT JOIN.
In addition, FULL JOIN is a also a synonym for FULL OUTER JOIN.
You might be interested in checking out the following article by Jeff Atwood:
Coding Horror: A Visual Explanation of SQL Joins
Duplicate of : Difference between JOIN and OUTER JOIN in MySQL
There is no diffrence between Right Join and Right outer Join both are same. i.e Left Join and Left Outer Join both are same.
This will give you clear idea :
Visual Representation of SQL Joins