Wednesday, October 24, 2012

Education, Practicality and an Introductory SQL Book

WS: I have a question. I have been asked about the possibility of teaching a SQL course. My audience will be people from a scientific rather than an IT background (which I think will make my job easier). If the training does take place then obviously in my own material I will cover the basics of the relational model before moving on to SQL. One of them has asked me if there is a book I can recommend on the subject to get them started. Now although I own a lot of books about the relational model and about SQL they contain mainly quite advanced material, I don't know of an introductory book about SQL that is theoretically sound. I wonder if you can recommend one? ... I haven't seen anything that I am particularly enthusiastic about. I would say it is a gap in the market, though unfortunately the market probably demands books about Oracle, Sql Server or MySQL. That is, of course, true of trade media and book publishers too.

An Amazon search on SQL gets a plethora of SQL books, but is any both 'theoretically sound' and for beginners? I don't know and if I had to guess, I very much doubt it. SQL teaching is approached mostly syntactically, devoid of proper relational context and is too close to products for comfort. What is more, technical product expertise and effective teaching skills are not the same thing and the combination is a rare one. But a core problem is that informal explanations of formal subjects that lose neither rigor and precision, nor an audience consisting of practitioners is non-trival, very tall order. The thing is, it has huge practical value.

The above email triggered a couple of thoughts. One is about an experience I had with academic teaching. A few good years ago I proposed to a local university an introductory database course. They were very interested because those with such knowledge are not keen on teaching for that kind of money when they can earn much more in the industry. My motive, however, was not financial, I wanted to catch young minds before they are corrupted.

Just like now, there was no book that fit the bill, which is why I later published UNDERSTANDING RELATIONAL DATABASES WITH EXAMPLES IN SQL. Some considered it the best introduction to the subject, which is why I keep getting queries about it (unfortunately it is out of print and somewhat out of date to recommend today--a 2nd edition is badly needed and I am trying to get one published). So, with my previous academic experience, I developed a syllabus based on selected papers and book chapters that I deemed most useful for the purpose.

But then I was quickly disabused of that intention: I was told that I must teach Oracle and use a specific book. But insisted on teaching my syllabus and gave students Oracle tasks for the lab based on the topics covered by it. Even that was not Oracle enough and the next semester they found a DBA who taught Oracle. How well? Did not matter: the students, their employers and Oracle were happy and, therefore, so was the school.

Here's another revealing detail about that course: the students kept pushing me for "practical stuff" (code for product training). But when for the final exam I gave them industry pronouncements/claims and asked them to apply what they learned in the course to analyze them, there were complaints that they expected to be examined on the syllabus material. So much for practical application of knowledge.

Since then the academia has increasingly become a vehicle for vendor certification. Research is on industry fads (XML, "BigData" and "the cloud"), rather than leading industry with science. The pressure from employers, students and vendors--particularly in the context of the education bubble--is just too strong to resist.

This evoked my second thought, about Edsger Dijkstra's comment from a speech about the industry's mode of operation:
I hope very much that computing science at large will become more mature, as I am annoyed by two phenomena that both strike me as symptoms of immaturity.

The one is the wide-spread sensitivity to fads and fashions, and the wholesale adoption of buzzwords and even buzznotions. Write a paper promising salvation, make it a "structured" something or a "virtual" something, or "abstract", "distributed" or "higher-order" or "applicative" and you can almost be certain of having started a new cult.

The other one is the sensitivity to the market place, the unchallenged assumption that industrial products, just because they are there, become by their mere existence a topic worthy of scientific attention, no matter how grave the mistakes they embody. In the sixties the battle that was needed to prevent computing science from degenerating to "how to live with the 360" has been won, and "courses" —usually "in depth!"— about MVS or what have you are now confined to the not so respectable subculture of the commercial training circuit. But now we hear that the advent of the microprocessors is going to revolutionize computing science! I don't believe that, unless the chasing of day-flies is confused with doing research. A similar battle may be needed.
--Edsger W.Dijkstra, My Hopes of Computing Science
With academia focused on XML, "BigData" and "the Cloud"), Dijkstra is probably turning in his grave.

Consider the following in that context:
It's that time of the year again. Introductory courses in relational data management (I'm a bit reluctant to call them "courses in relational theory") are starting again, all over the world, and consequently, students seeking advice and assistance from "professionals" start posing "Converting SQL to Relational Algebra" questions again on various database-related discussion fora, when they are not able to solve assignments given to them in class, or when they are uncertain their solution is correct.

I would actually like any of the teachers who give such assignments to try and explain to me what purpose they hope to be achieving by giving such assignments.  What do students learn from this? I recently got involved in such a "Converting SQL to Relational Algebra" question, and one remark the student made in the discussion that ensued, confirms my feeling regarding this: they learn nothing at all, and "Converting SQL to Relational Algebra" is completely pointless, only adding to the confusion instead of resolving it.  (The remark was, literally "we do not either understand why we are learning this".)

Why is this so?  Well, it's because Relational Algebra is foundational and SQL is not. That's because Relational Algebra is completely abstract and SQL is not. Not in the same sense that Relational Algebra is abstract ...
--Erwin Smout, Converting SQL to Relational Algebra
Here is more Dijkstra relevant wisdom:
The required techniques of effective reasoning are pretty formal, but as long as programming is done by people that don't master them, the software crisis will remain with us and will be considered an incurable disease. And you know what incurable diseases do: they invite the quacks and charlatans in, who in this case, take the form of Software Engineering gurus.

It is not the task of the University to offer what society asks for, but to give what society needs.

Teaching to unsuspecting youngsters the effective use of formal methods is one of the joys of life because it is so extremely rewarding ... The student that, like the wild animal being prepared for its tricks in the circus called "life", expects only training as sketched above, will be severely disappointed: by his standards he will learn next to nothing.

How do we convince people that in programming simplicity and clarity—in short: what mathematicians call "elegance"— are not a dispensable luxury, but a crucial matter that decides between success and failure? ... Why has elegance found so little following? ... it has the disadvantage, if that's what it is, that hard work is needed to achieve it and a good education to appreciate it. --WikiQuote 
For more Dijkstra wisdom and his work see E. W. Dijkstra Archive (University of Texas).

No comments:

Post a Comment

View My Stats