101–110 of 121 posts
See https://sqlbolt.com/ for an interactive SQL tutorial with less distracting examples.
This is good intiative. We need to simplify pedagogy. On a related note, I always found the syntax of SQL to be great. Someone told me that simplicity of SQL made relational databases even more popular. It is one of the best designed language where even someone new to the field won't feel intimidated. I'm surprised designers of SQL haven't won the Turing Award yet.
I teach SQL to financial people and, for the most part, it isn't too bad. When I get to joins, I teach a subset of SQL where all joins are done through INNER JOIN / LEFT JOIN syntax and that helps a lot. Joins are the part that everyone has trouble with.
> WHERE 0
> 1 and 0 are the most basic Boolean statements. This block guarantees that no rows will be returned.
This doesn't work in SQL Server and it has always bothered me. But is it part of any SQL standard?
The book also says this is an invalid where clause:
> WHERE '%obert%' LIKE first_name
> More than one wildcard is fine. But the pattern has to come after the LIKE operator.
This one is probably a bug/mistake, but it's definitely not invalid in the SQL language.
The choice of example database (the death penalty) is terrific. So much more interesting, important and compelling than the usual tired customer/product examples. I'm tired of seeing the implicit assumption around the place that software is just about business. Software should be about more than that.
I'm not the guy for trigger warnings but I find the choice of data unfortunate. There is a big percentage of people I won't recommend the page because of the dataset.
This is gorgeous, and a great topic. No matter what field you're working in, understanding databases is extraordinarily valuable...and SQL is among the longest lasting techs I've ever learned (e.g. name another programming language that is as valuable today as it was 20 years ago, if not moreso). Even with the rise of NoSQL databases, I suspect we'll all still need to know a little SQL in another 20 years (and it was…
> name another programming language that is as valuable today as it was 20 years ago, if not moreso * C * Python * Java 20 years ago was 1998.
This is good intiative. We need to simplify pedagogy. On a related note, I always found the syntax of SQL to be great. Someone told me that simplicity of SQL made relational databases even more popular. It is one of the best designed language where even someone new to the field won't feel intimidated. I'm surprised designers of SQL haven't won the Turing Award yet.
I agree except one thing: SELECT cols FROM table. This should really be FROM table SELECT cols as every modern SQL editor will then be able to show you a list of available columns. See LINQ. There they had the opportunity to fix it and it works just great.
This nullifies some other common sources of confusion, such as which statements are executed before a GROUP BY and which ones after (and why HAVING exists as a keyword). It's also similar to how CTE syntax is generally much more readable than subqueries.
This is gorgeous, and a great topic. No matter what field you're working in, understanding databases is extraordinarily valuable...and SQL is among the longest lasting techs I've ever learned (e.g. name another programming language that is as valuable today as it was 20 years ago, if not moreso). Even with the rise of NoSQL databases, I suspect we'll all still need to know a little SQL in another 20 years (and it was…
If we include non-Turing-complete languages as “programming languages”, which we must for SQL to get that 20-year label since SQL wasn't Turing-complete until recursive CTEs were part of the language, then XML.
Also, even without that caveat, candidates include Bash, C, C++, Objective-C, Perl, elisp, Java, JavaScript, MATLAB, VHDL, and others. Some, while still being as useful as they were 20 years ago, are down from a peak in the intervening period, but arguably that's true of SQL, as well.
Earlier quoted context omitted.
I agree except one thing: SELECT cols FROM table. This should really be FROM table SELECT cols as every modern SQL editor will then be able to show you a list of available columns. See LINQ. There they had the opportunity to fix it and it works just great.
I mean, it works either way. Once you type the column names, it can guess the table name easily. I use DataGrip at work and it can complete the column names without knowing the table name, so it ends up not being a problem.
If the query is simple enough that a natural join would work and you aren't doing FROM clause aliasing (which can be useful to make reusable queries self-documenting), sure.
For more complex queries and obviously any time table or column aliasing are used, that becomes somewhere between less likely and logically impossible.