Commonly here at the SQLTeam forums, users seeking assistance explain in long detail their situation and mention how they have millions of rows of data to deal with or dozens of tables and how complicated it all is.  Invariably, those of us offering help will be confused by the requirements (they often aren't stated very clearly or completely) and we'll ask for a small sample of data to work with.

It's funny, but the more I think about it, it's understanding how to generate that small sample set of data, and how to exclude trivial tables and/or columns, that is probably the difference between those who answer questions and those who ask the questions -- not knowledge of SQL or any specific programming technology.  The skill of breaking down a problem into small parts, excluding all the “extra” stuff that is not important, and then clearly stating the requirements and testing on a small sample is probably the most valuable attribute you can have.  Even the exercise of constructing a good set of sample data, ensuring that all possible cases are covered, is a process that requires you to think logically about the problem you are faced with. 

It seems like most users really are not having trouble with T-SQL or JOIN syntax typically, but rather understanding their own problem.  Nine times out of ten, if they can restate it more precisely and create a small sample set of data to work with, the answer is obvious and problem just about solves itself.   It's amazing how many people try to find the answer when they can't even state the question.

What always gets me, though, is that there are a surprisingly large number of people are almost too proud (if that's the right word) to do this.  They are professionals, used to working with huge amounts of data and complex SQL and all that. It is almost beneath them to put aside their 30 GB database and 10,000 lines of code to create a two column table with 2 rows, and another with 4 rows, to spend time testing out joins. If you aren't sure what happens when you do a FULL OUTER JOIN, don't test it on your General Ledger, create some sample data! 

So, take the time to step back on occasion, think logically about what your specific problem is, and instead of trial and error and hoping that things “look” correct, focus on small samples and easily verifiable results.  If you still can't solve it, come to SqlTeam with that sample data and the clearly stated description and I promise you that you'll get the assistance you need!

see also:

• Thinking Set-Based .... or not?
• What I learned about SQL from using Access
• How to be an Effective Report Writer
• Sometimes the problem isn't the code. It's the specs.
• Alias Naming Conventions
• Always Use Parameters. Even if you don't use Stored Procedures.
• Programming is a funny thing ....
• SQL Problem Solving: Identify ... and then Simplify!