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 :)

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.

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)

You can find most of the coursework from arsdigita here.

http://aduni.org/

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.

This book is over ten years old. Most of what you see there was in place in mid-2000.

I'v read this around that period. Learned a lot from it.

"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... but it is still a table with columns and rows.

Nope. Key/Value stores don't work this way, document stores don't work this way, graph databases... I don't think work this way.

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.

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.

The difference is described in http://code.google.com/appengine/docs/python/datastore/overv... 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.)

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

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.