Hacker News Reader

Comment by TrailMixRaisin | Hacker News Reader

While I think that you are right, but the right level of abstraction is super important. Here teachers should try to look at the business relevant applications. In university we had one course on databases. This was introduced by means of formal relational databases and relational algebra. Most of the students explained the stuff to each other by working with the more concrete translation in SQL. So if you had problems understanding what the restriction operation (σ) did, somebody told you that it maps to a SELECT in SQL.

View on HN

What's interesting is that I had my one database course in college that taught relational algebra. We had access to an Oracle database against which we probably only wrote a handful of queries. Almost all of the work was, well, math and theory.

When I got my first development job, I started out scribbling relational algebra on scrap paper and then translating it to SQL. I got faster and faster until I could think in SQL.

Agreed; you have to find a level that clicks for your students otherwise you're just throwing jargon at them. It's difficult to balance because knowing the subject well is required to teach it well, but knowing the subject well also means that your preferred abstractions are going to be too complicated [1].

A lot of people who want/need to understand the broad strokes of a database and how to query it effectively don't need to understand the deep, deep under-pinnings, and (unless you approach it cautiously) diving into it all will be actively counter-productive.

[1] https://xkcd.com/2501/

There should be examples (saying things like "oh, by the way, the projection operator is the SELECT clause of a SQL query" costs literally zero) but theory is important.

People who don't understand relational theory can't write SQL to save their lives.

I've seen schemas that literally made me scream.

I think the same applies to algorithms and data structures, e.g. red-black trees from the Cormen are literally std::map.

I found it to be a bit of a chicken-and-egg problem. At the time I learned it, I didn't really understand why relational theory was important. I trusted that it was, I just didn't really grok all of it. But later I found it of immense practical help when writing, and especially debugging, sql queries.

Perhaps the ideal order to learn in would be practical, theoretical, practical (applied theoretical), though that's just a gut feeling.

I dunno. I learned relational theory in college along with SQL. Since then, I've forgotten all of relational theory since I never used it for anything, but my SQL has improved quite a lot through use.

I'm thinking you may have a third variable problem here; people who write sucky SQL tend not to have spent a lot of time thinking about how to write non-sucky SQL. People who write non-sucky SQL have. The former has nearly zero chance to have been exposed to relational theory...the latter has a non-zero chance to have been. Correlation /= causation and all that, and the actual causative variable is time spent learning how to write non-sucky SQL.

> People who don't understand relational theory can't write SQL to save their lives.

Source?

From anecdotal experience, I've seen countless developers write reasonably acceptable SQL without even knowing relational algebra exists in the first place.

I think if they write decent SQL, they probably understand much of relational algebra, just not the standard notation and jargon.

Like a musician who can't read sheet music.

Relatedly, my experience is that learning relational theory and SQL first makes it harder to learn Microsoft Access.

I'm afraid that the converse might be true too, so I consider this to be a negative point for Access.

Reply on news.ycombinator.com