Ask HN: Review my introduction to SQL for Excel users Tutorial
querycell.com
querycell.com
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.
I will definitely keep the idea of more Excel parallel examples in mind for future tutorials.
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
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.
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 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.
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.
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.