October 23, 2009 at 5:07 am
al.gulseth (7/8/2008)
I couldn't even get to the guts of this article simply for the fact that I found the grammar/verbiage intolerable. Next time you should get someone who can clearly write in English to (at least) edit. It's like a resume with a word misspelled...right in the garbage.ps. Two words....Spell check.
Verbiage? The article was not overly wordy at all.
It was quite brief and to the point.
October 23, 2009 at 5:56 am
Cool. But I'd like to know if using INNER JOIN has less IO cost on DB than using a regular T1.PK1 = T2.FK2 ??
Thanks,
October 23, 2009 at 6:11 am
Gianluca Sartori (7/8/2008)
The concepts involved are really basic, so basic that I wouldn't even understand why sitting at your desk typing queries without perfect knowledge of these concepts.
I second that. Joins (especially inner joins) are the most basic part of any sql-language.
Even though it is used very often I have seen most people are not certain how it produces the result set when changing the join condition.
You're saying that most people write SQL without having a clue what they're doing? I find that really hard to belief...
Even when someone starts to learn SQL, this is so obvious stuff that with one glance at a query and its results your article will be redundant.
I'm really sorry to say, but this was a waste of your time as well as of mine....
October 23, 2009 at 6:42 am
Need to add Skill level or Complexity level to articles, so people would know this is an entry level article. Maybe a better title, like "Different types of Results for an INNER JOIN", there's nothing in here about the understanding what is happening in SQL Server with INNER JOINs.
October 23, 2009 at 6:43 am
alex_ortega (10/23/2009)
But I'd like to know if using INNER JOIN has less IO cost on DB than using a regular T1.PK1 = T2.FK2 ??
Nope. Optimiser will generate identical execution plans. Write a query both ways and check the exec plan.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
October 23, 2009 at 6:45 am
Absolutely agreed.
October 23, 2009 at 6:47 am
Some of us American-English speakers prefer to consider it UEE - Un-colonized English English
:-D:-P
---------------------------------------------------------
How best to post your question[/url]
How to post performance problems[/url]
Tally Table:What it is and how it replaces a loop[/url]
"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."
October 23, 2009 at 6:54 am
Very good article. It makes the INNER JOIN concept crystal clear.
October 23, 2009 at 7:22 am
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.
October 23, 2009 at 7:30 am
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.
October 23, 2009 at 8:54 am
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.
October 23, 2009 at 9:13 am
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.
October 23, 2009 at 9:18 am
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. 🙂
October 23, 2009 at 9:32 am
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).
October 23, 2009 at 10:38 am
From the looks of it an innter join is the same a just a plain join. Why use the word "inner"?
Viewing 15 posts - 106 through 120 (of 134 total)
You must be logged in to reply to this topic. Login to reply