A few thoughts.

1) I like the visualization. Its a key part of understanding SQL.

2) However, I don't see this as taking advantage of a user's excel knowledge. Why not make an analogy they will understand? Join is similar to vlookup! Try to do something in excel first and then do it SQL. That will be tough for advanced SQL, but should be (sort of) doable early on. So far, someone with advanced knowledge of excel wouldn't be much better off than someone just getting started.

3) Someone might ask the question: "Why have the from clause? Why not always do "select person.first_name where....?" I don't know how your will answer this...

4) In your explanation of having the same column name in two places, why not use email address? People have email addresses as well as companies. You mention a customer table but the student can't see one, so it could be confusing.

I think there is the possibility of doing some great stuff with the excel SQL analogy...

As for future topics: Keep in mind what you can do with excel and go from there. Sums, products, etc... can all be done. Inserts are tougher to explain, I'd keep it for later when you have people thinking in SQL and not excel.

Thanks for the fantastic feedback roundsquare.

I will definitely keep the idea of more Excel parallel examples in mind for future tutorials.

Hi,

I've got an add-in for excel product that allows the use of SQL in Excel, so I have created a basic introduction to SQL tutorial.

I would appreciate any feedback you have.

It aims to be practical and doesn't worry too much about relational theory or the more intricate aspects of databases/sql.

Although I'm planning to get into the more complex uses of SQL in later tutorials.

Cheers Sam H

It's good. I would have found this helpful a few years ago.

How about putting the tables into normal form? ie where you currently have the company name as a string in the Person table, instead have an ID which references the Company table. It's not necessary for understanding the example shown, but it can't hurt to start off with good practice.

Thanks for the feedback.

I considered introducing surrogate keys but thought it was probably not a good idea in the first tutorial. I will have a think about adding them in or covering them in the next tutorial.

I spent a lot of time in a previous life making huge queries in SQL and then dumping the un-normalized data into Excel to use its amazing Pivot functionality. I like the idea of this plugin, wish it worked the other way around!

gsiener : Do you mean you wish you could use it to bring data from a SQL database into Excel rather than use SQL on Excel data ?

I have considered adding this functionality, allowing the user to connect to any data source. It become pretty complex pretty quickly though, supporting a query that joins tables in different databases, with their different types, would be a big challenge.

I like the format but I wish to see more.

Excellent.

Do you have any particular topics you would like covered ?

I think the next tutorial will cover different kinds of joins and perhaps aggregate functions and inserts. But I will cover what people ask for.

Thanks for the feedback.

I would skip inserts - more than likely your users will insert the data the way they're used to, by adding a row to the Excel table they're using.

If I understand what your niche is (power users who are comfortable with Excel), I would focus on things like aggregates and grouping functions - as of now, you've told people how to join a table, but not why they'd want to (or how it's better than what they're currently doing). I'd also integrate how to do this using your specific program.

In short, don't focus on teaching SQL in the abstract. Focus on teaching the SQL you need to use your program, and why it would be useful to do so.

Thanks for the feedback JimmyL, food for thought.