Is it possible to select multiple options inside this box?
No you can't, nor does it make sense to. When writing a query you need to be specific on what you want, and how you want that data to relate
Take the image in your question, where you are selecting a table name, if you select 2 tables, how is that meant to appear in the query? To have 2 tables in the query you need a JOIN. What type of JOIN should that be? An INNER JOIN? a LEFT or RIGHT OUTER JOIN? Perhaps a FULL OUTER JOIN or even a CROSS JOIN? If any but the last, what is the ON clause for said JOIN?
What about if it were a function? Would the other functions be called with a CROSS APPLY or an OUTER APPLY? What are the values of the parameters?
Intellisense doesn't know what you want, only you know that. It's prompting potential options to you, in this case objects that match the name of what you've typed already, but it doesn't know what you're going to do with those objects afterwards. It's not able to predict your intentions; it's just listing objects names that match your existing text.
Intellisense is there to assist you write the queries but it's not there to literally write them for you; that's for you to do.
Related
I am using t-sql on various sql server versions.
From the moment I learned about cross apply, I have been using it quite frequently. The specific kind of use I want to discuss is the use of one
cross apply (select really_long_statement where correlated_join_condition) as tablename(fieldname)
statement. I am using this to make code clearer, as I have read here on the "Introduce new columns!" section:
http://bradsruminations.blogspot.gr/2011/04/t-sql-tuesday-017-it-slices-it-dices-it.html
It is obvious to me that the exact same function of the statement I mentioned earlied can be achieved by this:
inner join (select correlated_join_condition_fields,really_long_statement) as tablename(fieldname) on correlated_join_condition
Being a little lazy, initially I would prefer the first solution, because i do not have to type twice the join condition fields.
Then I thought, cross apply is less known and used from inner join, so maybe it would be a good idea to stick to inner join for the sake of writing easier to maintain code.
But then, I peeked the query plan for an instance of those two scenarios, and noticed the cross apply was actually faster!! I did not expect this; from all the posts I've read about plans, it seems that most of the time, when two queries do the same thing and are not hugely different, the plan analyzer will figure this and make the same plan.
I am not able to upload the plans at the time of writing this, but I will be able to in a couple of days.
So, the question is, why does cross apply seem faster? Is it because it does not have to make the join condition fields available?
Plus any opinions about the balance of performance/easy to read code/short to write code would be welcome.
I feel a bit stupid for asking this, because I'm sure there is a simple other type of join I should be using, however, I can't seem to find the answer, so I'm hoping one of you can point me in the right direction.
I have a big query in Access 2007 that pulls in records, but in some cases, I can't use an INNER JOIN on some tables, because linking records may not exist, so the main record rightly drops off. I can get round this problem by using IIF statements, checking if an entry exists first, but this makes the query terribly slow. I simplify the scenario below. Many thanks in advance:
Use a LEFT JOIN instead of an INNER JOIN.
I have a doubt about how to properly use JOIN SQL queries.
Imagine that I have 3 tables. I want to make a RIGHT JOIN between two of them. This is, I want to show all the records from the left table and just those records from the right table where the join is equal. Once I have this, I want to make another JOIN (inner or whatever) between the table that was on the right (now is the LEFT table) and the third table (that is the RIGHT table). So that, I would have 3 tables connected. My problem is that I get a message error from access that is:
The SQL statement could not be executed because it contains ambiguous
outer joins. To force one of the joins to be performed first, create a
separate query that performs the first join and then include that
query in your SQL statement.
So, Access is forcing me to use two separates queries but I don't want to use two. I think that this must be possible in just one. Am I right? Do you know if there is a method for this?
Thank you all.
Can you try this ?
Put the inner join first
Source : Source
This question already has answers here:
Odd INNER JOIN syntax and encapsulation
(1 answer)
Join statement order of operation
(1 answer)
Closed 9 years ago.
I came across this horrifyingly freakish SQL query today that another developer generated with the SQL Server query designer tool. I hate the query designer, but I'm stuck trying to figure out what it did. I've never seen syntax like it before and don't understand it. How does it work?
In particular it is is the multiple ON clauses joined together separate from the JOIN clauses that is throwing me off.
SELECT *
FROM dbo.tblDealStatus
RIGHT OUTER JOIN dbo.tblUser
RIGHT OUTER JOIN dbo.tblOwnerLocation
INNER JOIN dbo.tblOwner
INNER JOIN dbo.tblDeal
ON dbo.tblOwner.OwnerID = dbo.tblDeal.OwnerID
ON dbo.tblOwnerLocation.DealID = dbo.tblDeal.DealID
ON dbo.tblUser.UserID = dbo.tblDeal.CHK_Contact
LEFT OUTER JOIN dbo.tblCompany AS tblCompany_1
INNER JOIN dbo.tblParticipation
ON tblCompany_1.CompanyID = dbo.tblParticipation.CompanyID
ON dbo.tblDeal.ParticipationID = dbo.tblParticipation.ParticipationID
ON /*...
....so on and so forth...*/
First, I make it rule for clarity to never mix right and left joins in the same query. All right joins can be switched to left joins and that alone will make it easier to figure out what is going on.
Next abandon select *. It is never appropraite in a query with joins as you are returning the same data in two or more fields (the join fields) and that is wasteful of valuable network and database processing time.
I believe the wierd ONs are forcing the query to go in a particular order. They are bad and should not be used in my opinion as they are hard to maintain and hard for developers to understand as they are not common and are totally unneeded. Just reversing the right joins and putting the tables in the order you need to join them may fix this. If not you may need a few derived tables to get the right data. Note that in reversing it, you may need to change those inner joins to something else. Right now it is such a mess, it is highly likely it does not return the correct results. So in rewriting it, while you would want to see if your changes change the results, you would also want to use judgement to determine if the changes are fixes for a bad query or incorrect changes to translate the query into something maintainable.
If the developer who wrote this mess is still there, I would force him to rewrite in in more standard SQL and tell him he is forbidden to ever use the query designer again. This fails code review as far as I am concerned.
If I were rewriting this, I would look for the table that should be first in the query and work down from there. My personal guess right now is that it would be the tblDeal table but I don't know your data model so I could be wrong.
It seems like to combine two or more tables, we can either use join or where. What are the advantages of one over the other?
Any query involving more than one table requires some form of association to link the results from table "A" to table "B". The traditional (ANSI-89) means of doing this is to:
List the tables involved in a comma separated list in the FROM clause
Write the association between the tables in the WHERE clause
SELECT *
FROM TABLE_A a,
TABLE_B b
WHERE a.id = b.id
Here's the query re-written using ANSI-92 JOIN syntax:
SELECT *
FROM TABLE_A a
JOIN TABLE_B b ON b.id = a.id
From a Performance Perspective:
Where supported (Oracle 9i+, PostgreSQL 7.2+, MySQL 3.23+, SQL Server 2000+), there is no performance benefit to using either syntax over the other. The optimizer sees them as the same query. But more complex queries can benefit from using ANSI-92 syntax:
Ability to control JOIN order - the order which tables are scanned
Ability to apply filter criteria on a table prior to joining
From a Maintenance Perspective:
There are numerous reasons to use ANSI-92 JOIN syntax over ANSI-89:
More readable, as the JOIN criteria is separate from the WHERE clause
Less likely to miss JOIN criteria
Consistent syntax support for JOIN types other than INNER, making queries easy to use on other databases
WHERE clause only serves as filtration of the cartesian product of the tables joined
From a Design Perspective:
ANSI-92 JOIN syntax is pattern, not anti-pattern:
The purpose of the query is more obvious; the columns used by the application is clear
It follows the modularity rule about using strict typing whenever possible. Explicit is almost universally better.
Conclusion
Short of familiarity and/or comfort, I don't see any benefit to continuing to use the ANSI-89 WHERE clause instead of the ANSI-92 JOIN syntax. Some might complain that ANSI-92 syntax is more verbose, but that's what makes it explicit. The more explicit, the easier it is to understand and maintain.
These are the problems with using the where syntax (other wise known as the implicit join):
First, it is all too easy to get accidental cross joins because the join conditions are not right next to the table names. If you have 6 tables being joined together, it is easy to miss one in the where clause. You will see this fixed all too often by using the distinct keyword. This is ahuge performance hit for the database. You can't get an accidental cross join using the explicit join syntax as it will fail the syntax check.
Right and left joins are problematic (In SQl server you are not guaranteed to get the correct results) in the old syntax in some databases. Further they are deprecated in SQL Server I know.
If you intend to use a cross join, that is not clear from the old syntax. It is clear using the current ANSII standard.
It is much harder for the maintainer to see exactly which fields are part of the join or even which tables join together in what order using the implicit syntax. This means it might take more time to revise the queries. I have known very few people who, once they took the time to feel comfortable with the explicit join syntax, ever went back to the old way.
I've also noticed that some people who use these implicit joins don't actually understand how joins work and thus are getting incorrect results in their queries.
Honestly, would you use any other kind of code that was replaced with a better method 18 years ago?
Most people tend to find the JOIN syntax a bit clearer as to what is being joined to what. Additionally, it has the benefit of being a standard.
Personally, I "grew up" on WHEREs, but the more I use the JOIN syntax the more I'm starting to see how it's more clear.
Explicit joins convey intent, leaving the where clause to do the filtering. It is cleaner and it is standard, and you can do things such as left outer or right outer which is harder to do only with where.
You can't use WHERE to combine two tables. What you can do though is to write:
SELECT * FROM A, B
WHERE ...
The comma here is equivalent to writing:
SELECT *
FROM A
CROSS JOIN B
WHERE ...
Would you write that? No - because it's not what you mean at all. You don't want a cross join, you want an INNER JOIN. But when you write comma, you're saying CROSS JOIN and that's confusing.
Actually you often need both "WHERE" and "JOIN".
"JOIN" is used to retrieve data from two tables - based ON the values of a common column. If you then want to further filter this result, use the WHERE clause.
For example, "LEFT JOIN" retrieves ALL rows from the left table, plus the matching rows from the right table. But that does not filter the records on any specific value or on other columns that are not part of the JOIN. Thus, if you want to further filter this result, specify the extra filters in the WHERE clause.