Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase «««1011121314»»»

Understanding INNER join in detail Expand / Collapse
Author
Message
Posted Friday, October 23, 2009 6:45 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Thursday, March 27, 2014 12:29 PM
Points: 9, Visits: 30
Absolutely agreed.
Post #807820
Posted Friday, October 23, 2009 6:47 AM


SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Yesterday @ 8:12 AM
Points: 2,627, Visits: 19,093
Some of us American-English speakers prefer to consider it UEE - Un-colonized English English



---------------------------------------------------------
How best to post your question
How to post performance problems
Tally Table:What it is and how it replaces a loop

"stewsterl 80804 (10/16/2009)I guess when you stop and try to understand the solution provided you not only learn, but save yourself some headaches when you need to make any slight changes."
Post #807823
Posted Friday, October 23, 2009 6:54 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: 2 days ago @ 9:11 AM
Points: 1, Visits: 52
Very good article. It makes the INNER JOIN concept crystal clear.
Post #807835
Posted Friday, October 23, 2009 7:22 AM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Today @ 9:50 AM
Points: 154, Visits: 381
When did this community become full of elitist jerks?

This was a very basic article but there are a lot of people in the database field who do not have any fundamental concepts. This is useless for anyone past beginner but is a godsend from someone who just got in the field or some student trying to learn joins. If anything it gave me another way to explain joins to people who do not understand them. Great article just for this reason.

The grammar was horrible but anyone with a firm grasp of the English language could read through that and understand the author. I bet half of you post in all caps on facebook/myspace. I won't disagree that it detracts from the article and should be corrected but you can still get the basic concepts from the examples.

P.S. Programming languages (like T-SQL) are not english. They just look english but have their own syntax and semantics. They don't call them Programming Language for nothing.
Post #807864
Posted Friday, October 23, 2009 7:30 AM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Today @ 9:50 AM
Points: 154, Visits: 381
Simon Facer (7/8/2008)


And (I know other have said it already) PLEASE quit complaining about the lady's command of the English language. We are a community of SQL Server professionals, we are here to help each other and disseminate tips and tricks we learn, not to flame one another for spelling mistakes. Everyone who flames reduces the tone of the site, not the user who takes the time to submit an article, no matter the level of the article.


+1

As for
jpellman (7/8/2008)
Please read your work before publishing content. English is America's language - God bless America!!!
If I write colour (with a 'u') instead of color, are you going to correct me. After all, that's English, but not American English, please don't be so jingoistic in your attitudes (http://dictionary.reference.com/browse/jingoism).




Thank goodness for this post. I wanted to flame that guy so bad for that statement but then I would have been wrong.
Post #807871
Posted Friday, October 23, 2009 8:54 AM
SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC Rookie

Group: General Forum Members
Last Login: Monday, July 16, 2012 10:19 AM
Points: 46, Visits: 177
Good article. I actually didn't have to read it to get it; so I didn't notice the errors. This was due to the use of the Cartesian product as the basis of each illustration. The only way to improve it - other than correcting the typos - is to describe the situations that warrant the use of the unequal JOINs. I like stories.
Post #807965
Posted Friday, October 23, 2009 9:13 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Tuesday, January 21, 2014 1:37 PM
Points: 3, Visits: 60
Nice article and clear explanation of these very simple scenarios. While it is true that one can extrapolate from these examples to write other queries, I would really like to see a similar approach that tackles multiple joins on the same and different tables in the same statement. In the dev world I've lived in the past twelve years there are precious few times when all I needed was a single join between only two tables.


Post #807978
Posted Friday, October 23, 2009 9:18 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Tuesday, October 27, 2009 8:45 AM
Points: 2, Visits: 9
I skimmed the article so I missed all the typos / grammar mistakes and perhaps they've been corrected by this point. I use inner joins all the time for joining tables and I've occasionally used the full outer join to join a table with single row to another table with multiple rows. I guess I might do the not equal join to see how many rows in Table B didn't match the one in table A that I am interested in. But I can not figure out why I would would ever care about the ID's in B that are greater than or less than the ID in A.
There are two schools of thought on the PK. One says they should be arbitrary numbers that have no significance aside from being the PK. The other says use some human friendly unique ID (like perhaps a Social Security Number or Customer Account Number or Phone number). Personally I go with the first (arbitrary number with no meaning attached to it) the human readable ones tend to change too often and have other issues. So when it's an arbitrary number why would I care if one arbitrary number from Table A is greater than or less than the arbitrary numbers in Table B?
Don't get me wrong I liked the examples, but like someone else posted. I would like a story to with them so I could see how I could use them. I thought the use of the Cartesian product at the beginning was very good because it made the other examples immediately understandable.
Post #807982
Posted Friday, October 23, 2009 9:32 AM
SSChasing Mays

SSChasing MaysSSChasing MaysSSChasing MaysSSChasing MaysSSChasing MaysSSChasing MaysSSChasing MaysSSChasing Mays

Group: General Forum Members
Last Login: Tuesday, March 04, 2014 7:41 PM
Points: 634, Visits: 399
I gained both from the article's graphic examples and from its use of SCOPE_IDENTITY() in INSERTing rows into the 1st table. Thanks to whomever (Steve Jones?) made the requisite corrections to the original article (e.g. adding "int" in the definition of the 2nd table).
Post #807993
Posted Friday, October 23, 2009 10:38 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Thursday, April 26, 2012 6:24 AM
Points: 3, Visits: 10
From the looks of it an innter join is the same a just a plain join. Why use the word "inner"?
Post #808049
« Prev Topic | Next Topic »

Add to briefcase «««1011121314»»»

Permissions Expand / Collapse