I created http://sqlteaching.com , so it's wonderful to see Khan Academy's take. If anyone from KA would like to chat with me about SQL tutorials or anything else in general, feel free to reach out- firstname.lastname@example.org
As a request, are you working on a user system to record completed lessons? As an extension, are you looking into making a classroom management system akin to Codecademy? I'd love to create a classroom, have students log in, complete the necessary lessons and have the means to know where they are in the overall plan.
If you'd like some help getting that going, let me know! I'm in the process of developing typing exercises for my courses to give students extra practice with the basics.
KA does have classroom tools and progress reports, but we don't have the ability for teachers to create their own lessons (if that's what you're looking for). More details on that here: https://www.khanacademy.org/coach-res/reference-for-coaches/...
It's a lot of work to create the classroom management itself (that's done by a whole separate team at KA) so it's not something most folks tack on to teaching sites.
Thus, I would have a bias against adding a classroom management system which would require some kind of backend database that I would need to keep running (funny, I know).
Also, I made my share of contribution to the SQL pedagogy by writing blog articles on "SQL for Excel Users":
I am curious if you know a resource that would start approximately where your site/tool stops. I know there are books and reference manuals - but I would love to see the intermediate SQL version of your tool - including things like cursors, stored procedures and Common Table Expressions.
Or does SQL at the next level lose too much of its uniformity? And, you would have to make separate sites for PostgreSQL, MySQL, SQL Server etc.
Unfortunately, I don't know of interactive tutorials that cover the things you mentioned. The Khan Academy tutorial and SQL Bolt seem to have a few topics not covered by SQL Teaching, so that is a start! (Mainly, write queries)
SQL Teaching uses SQLite because that way I don't need to maintain a backend to the site.
But if there are more advanced topics that can be taught by SQLite, feel free to make a issue in the repo. Pull requests are also welcome!
I guess I will just keep learning as the need becomes apparent. Anyway thanks for making your resource available.
Been using SQL for a while now but never got the hang of joins and could never find an easy guide for them. This was the simplest explanation I could find.
They mentioned pronunciation : 'S-Q-L' vs 'sequel'. I've always pronounced it S-Q-L. The lecturer implies there's no right answer, that 'sequel' is historical but 'S-Q-L' is preferred for international use.
The annoying thing, though, is that in writing a choice has to be made. If someone pronounces it 'S-Q-L' then to read 'a SQL query' is weird -- it should say 'an SQL query'. And vice versa for someone who pronounces it 'sequel'. 'an sequel query' isn't right.
So, in writing, what is correct? 'An sql query' or 'a sql query'?
That said... As a native English speaker, I can infer your pronunciation from which of the options of "a" and "an" you decide to use.
FWIW, "an" is appropriate for any word starting with a vowel sound (whether or not it actually starts with a vowel) and inappropriate for any word that doesn't. "An historic" drives me nuts, but I'm one of those jerks. (My mother was an English teacher - I never stood an chance!)
Aside: the reason "an" is also sometimes used for word starting with an "h" is that the "h" in those cases is silent and the pronounciation therefore starts with a vowel (following the silent "h"). There are some style guides that recommend using "an" for words where the "h" isn't silent (or "a" for words where it is) but they're just being intentionally obtrusive.
Worse is that some writers seem to mix it up, use both periodically.
Importantly, people who have only ever read the abbreviation, and not heard it spoken aloud, will assume it's a plain initialism. It's better, I would think, to write something that reads properly to these people—something "more accessible."
The people who are aware of the acronym pronunciation, meanwhile, will be able to adapt their reading either way, because they're also aware that a plain-initialism reading exists, so you're not unduly burdening them in parsing the sentence.
But that doesn't answer your question. I suppose it's the same as when saying it. Pick one and stick with it, whatever your choice.
Of course, if its a work on SQL, you can normally avoid "a(n) SQL query" and just say a "a query" (with SQL implicit from context) or, in the less-common situation where you need to distinguish it from a query in a different query language, "a query in SQL".
In English, however, there is no such authority. Whether you are writing a SQL query or an SQL query is all up to you. Aren't you happy you don't have an old wrinkly white French dude to chastise you about which one is correct?
FWIW, I use sequel as that's how I learned it. But I also dislike unnecessary syllables so that's my justification.
The audio that highlights part of the code is awesome (much better than watching a passive video), and the fact that everything can be executed in real time is awesome. Good job!
I created http://pgexercises.com a while back, which goes up to some relatively tougher exercises. I'd be very happy to help out with KA's effort if it would be useful. Email is in my profile.
First, it's not teaching standard SQL, it appears to be teaching MySQL. That means any user who tries out any other system will immediately run into confusing error messages about the double quotes. Not ideal, and totally unnecessary -- sticking to standard SQL should work reasonably well in MySQL anyway (at the beginner level, at least).
Second, in the section "Creating Tables and Inserting Data", the teacher jumps into surrogate keys immediately. Again, I feel that is unnecessary and will just lead to confusion. The beauty of a relational database is that it connects with the real world; and having arbitrary numbers floating around destroys that beauty.
I really hate to criticize, because I really support the effort. Hopefully my feedback is useful.
I have learned a lot of SQL at my current job, though. I can now admin multiple types of DB servers and write SQL up through window queries, CTEs, indexes, stored procedures, etc, so I've learned enough to be past the end of every SQL lesson I've ever seen. There's a huge amount of fascinating stuff to learn and a ton of cool stuff you can do.
Actually I'm a back end developer and I don't use SQL at all. I learned it (a bit at least) on my own just out of interest and random personal projects, but I don't use SQL at work at all; we only use DynamoDB.
That's just one example. I'm sure there are many.
I know Prolog pretty well so it's not like I was completely flabbergasted by it, I just had no need to use SQL before.
You could write every application under the sun without knowing a single bit of SQL.
Big data analytics is increasingly done with Hive's SQL dialect, or Impala, or Hawq. Beyond all of these, relational data modelling is an essential skill for anyone building server side applications if you have to deal with information management, whether you use SQL or not.
But I agree with the spirit of what you're saying. A good programmer will know SQL. It's definitely not going away anytime soon.
Is this set theory? A UNION of two sets? Oh I see your pedantic argument. They aren't sets because they are ordered, they are lists.
If I can't explain how UNIONS and INTERSECTS are relevant to SQL to you then I can't help you because you're simply being difficult. It has every practical application to SQL.
> They aren't sets because they are ordered, they are
Were I being pedantic, I would turn to the (horrifyingly inconsistently written) SQL1992 standard, which explicitly says that your columnar inputs are multisets (which is a posh way of saying "not a set").
Coming back to your original assertion:
>> you will still have to understand the basics of set
>> theory. Unions, intersects
But most people don't write SQL by hand any more, they use an ORM - most of which have scant support for UNION, INTERSECT, and EXCEPT, because they are obvious vestigial details left over from archaic database theory. I have resisted the temptation to become actually pedantic by discussing the SQL treatment of NULLs.
This constitutes "almost no practical overlap".
But look, here's the meat: Fundamentally, sets are distinguished from other list-like data types by having no ordering, and having no repetition. Practical SQL usage requires you to understand that you will have duplicates, that you may well need to aggregate those duplicates somehow, and that order matters.
Huh, I guess others think like I do.. I guess we're all morons. Shrugs.
> Huh, I guess others think like I do..
> I guess we're all morons
Or you could develop software that doesn't use relational databases for persistence; there's still lots of that.
Grim. Barbed wire enema.
Wiped out my Windows boot
partition requiring that I
reinstall everything starting
with the Windows DVD.
The stuff with users,
logins, etc. and nearly
everything in SQL Server
Management Studio was
clear as mud. In the end:
(A) Assume that basically what
is there is essentially old
capabilities and access
control lists, imagine how
they might work, and make that
a first guess. It helped.
(B) Use SQL Server Management
Studio only for passively reading
but never for actual management
where change things.
(C) For each of the important
steps in setting up
security, do searches on the
Internet, find standard
text SQL statements, and
try those. Save and profusely
document the statements that do work.
(D) Do system management
only with SQL statements in
simple text files and executed
with the SQL Server
command line utility
(3) Connection String.
The last time I had to get
a SQL Server
connection string to work
took a solid week of
throwing things against
a wall to see if they would stick.
The effort was an
unanesthetized upper molar
root canal procedure.
http://downloadsqlserverexpress.com/ is a nice source to install SQL Server and Management Studio from, which also has a link to a blog post kinda mocking how ridiculously hard it is to find the installer on the Microsoft website.
I also find it odd just how long it takes to install, versus Postgresql on Windows installing in like 5 minutes I think.
I'm not sure what you're trying to do with users and permissions, but I haven't had much trouble with that in Management Studio. Add a new login in the server Logins folder, set either a username/password or domain authentication, select databases and set permissions. Not that I've tried anything tricker like assigning multiple users to a role, or doing stuff with AD groups.
https://www.connectionstrings.com/ is a decent resource for connection strings too. It seems to be pretty easy, as long as you're connecting from other Microsoft tools, like Management Studio, sqlcmd, ADO.NET, etc. I'm pretty sure I once spent like a day or so trying to figure out how to get ActiveRecord to connect to SQL Server before I got it working.
That said, the usual lessons could stand to pay more attention to this kind of management stuff.
I've got SQL Server working
now with notes on how I did it
and with some simple text files
with SQL commands to be run
with the Microsoft SQLCMD.EXE
for setting security.
For the connection string,
I found something that is working
and, of course, have it documented,
saved, etc. To define the
tables and columns, I have that also
as just simple text in a file
run with SQLCMD.EXE.
To keep SQL Server installation
problems from ruining my boot main
partition, finally I am good
at using NTBACKUP to get a
clean backup and know how to
restore it. So, before doing
anything like a SQL Server install,
I will use NTBACKUP to save
the main boot partition.
If SQL Server messes up, then,
boom, I will just restore the
boot partition and start over
with the SQL Server install.
The worst time with SQL Server
installs it wasn't clear what
the heck to click on, ended
up with two versions installed
side by side, tried to uninstall
one, and ended up with a sick
SQL Server that wouldn't do
even the simplest things.
Another time I wanted SQL Server
to use a database from
an earlier install, and trying
to do this got SQL Server sick.
Trying to uninstall and reinstall
ruined my boot partition.
But, as soon as I can get the
other work done, I will get
the first server computer
for my "server farm", install
some recent versions of Windows
Server, SQL Server, IIS, etc.
and go live. Then, with
Windows Server, etc., I will
be back into system management
Today I am fixing a bug in
my Web site: I have two
Web pages where they use
to send a user from one to the
other, and I have a fairly
elaborate session state to be
saved in one page and restored
in the next one (instead of
Redis, wrote my own session
state store with just
byte strings of instances of
my session state class and
two collection classes). But
going between the two pages
I must have coded when
half asleep and didn't get
quite right. So fixing that now.
Also putting in lots of documentation
to make it clear just what
is going on.
My wisdom in building a Web
site with ASP.NET: Start with
the class for the session state
you want for your site.
That is, concentrate on this
data, with essentially global
scope. The first crucial work
is just being really clear on
just what the session state data
is to be.
The second most
important thing is to be clear
on just how ViewState works.
ViewState is useful and
can save some coding.
Third, in positioning things
on the Web page, maybe
make good use
of instances of the class
Fourth, have clearly in mind
all the data that is available
from a post back -- some of that
data can be useful.
Fifth, make good use of the
ability to write data to the
clearly in mind when
the button click routines
After that, just keep it
all simple and clear for the
That was easy. Think of it
as close to set theory!
I needed to get through all the
overhead stuff since I'm using
SQL Server in the server farm
for my startup. So, I have
code for Web pages
with ADO.NET and also some
stand alone programs that
do SQL Server queries.
Again, the only difficult
stuff was the overhead stuff,
and it would appear that the
Khan course would not cover that.