
SQL for Web Nerds - mbowcock
http://philip.greenspun.com/sql/
======
ericmsimons
Great reference. I come from a lot of MySQL background so this was very
informative. I also appreciate the lack of crazy CSS and graphics; it makes
the content easier to skim and read. Same reason why I love HN :)

~~~
cd34
I would be surprised if that page wasn't at least 5-6 years old. Philip
Greenspun founded ArsDigita which released the software known now as OpenACS.
His thought processes were quite interesting and his theory on hiring the top
.2% of the programming elite were radical at the time, but, proved to be quite
on-the-money. The implosion of that company has been told on the net many
different ways, but, some of his methods still hold quite a bit of merit.

~~~
cellularmitosis
Your comments about ArsDigita reminded me of ADUni
(<http://en.wikipedia.org/wiki/ArsDigita_University>), which hosted free video
lectures of an intensive one-year computer science curriculum. Back in the day
I had attempted to download these lectures, but a slow pipe and the large
number of lectures / assignments / etc discouraged me from finishing.

Lo and behold, the modern era of youtube and google video has seen the
resurrection of these videos. Someone named "Chao Xu" has uploaded (nearly)
all of the videos to google. see <http://mgccl.com/2008/04/06/aduni-videos-
now-on-google-video>

(in fact, there's even a course on databases)

~~~
mbowcock
You can find most of the coursework from arsdigita here.

<http://aduni.org/>

~~~
cellularmitosis
also, I just realized archive.org has a complete mirror of all of the
lectures, exams, etc.

<http://www.archive.org/details/arsdigita>

EDIT: actually its only the first 8 courses (there are 12 total).

EDIT: wrong again; they have all 12 courses, but only list the first 8 on the
landing page.

------
zeynel1
"Each table in the database is one spreadsheet. You tell the RDBMS how many
columns each row has."

If this is not a relational database this is still true. Correct? For
instance, Google App Engine, pretends to be not a a table
[http://stackoverflow.com/questions/4731657/google-app-
engine...](http://stackoverflow.com/questions/4731657/google-app-engine-is-
not-creating-table-python/4731741#4731741) but it is still a table with
columns and rows.

~~~
btilly
This statement _can_ be true if you don't have an RDBMS. But generally isn't.

For instance with Google App Engine there is no way to say, _My columns are
foo and bar_ then have it tell you that you've done something wrong when you
try to insert something into column baz.

~~~
zeynel1
I guess I don't understand the distinction then. In the App Engine what is
called a Model in the script looks like a table to me. It has rows and it has
columns and those rows and columns contain data.

~~~
btilly
The difference is described in
[http://code.google.com/appengine/docs/python/datastore/overv...](http://code.google.com/appengine/docs/python/datastore/overview.html#Differences_From_SQL)
with:

 _Unlike traditional relational databases, the App Engine datastore doesn't
require data kinds to have a consistent property set (although you can choose
to enforce this requirement in your application's code)._

Here is what they mean by that. In a traditional relational database every
table must have a table definition that specifies all of the columns and
column types. In the App Engine it is up to the application to supply an
implicit table definition. And there is no enforced consistency. If two
applications access the same table, they can put entirely unrelated kinds of
objects there. (Or, worse yet, put related objects that are just _slightly_
different. Just to confuse you.)

~~~
zeynel1
Ok. In that case, they are both tables; but they have different properties.

~~~
btilly
It is an important distinction to make. Relational databases are all about how
to structure your data, and then how to manipulate that structure. In
particular a key value add is that because the database understands how your
data is structured, you can tell it what data you want out, and _it_ can
figure out the most efficient way to extract that data.

In practice it isn't perfect. There are times that the database does things
wrong, and it is useful to have a bag of tricks for figuring out when it is
going wrong and forcing it to do the right thing. But _on average_ it does
much, much better than _most_ developers could, and does it with a lot less
work.

