3 ms·

The course covered relational algebra and calculus before even talking about SQL This is the peril of leaving programming education to the computer scientists:

The course covered relational algebra and calculus before even talking about SQL This is the peril of leaving programming education to the computer scientists: People are routinely forced to rebuild a car's engine before being told what a stoplight is or how to merge onto the freeway. And it might help explain why my coworkers think I'm some sort of RDBMS genius when all I've ever done was read SQL for Web Nerds: Database researchers love to talk about relational algebra, n-tuples, normal form, and natural composition, while throwing around mathematical symbols. This patina of mathematical obscurity tends to distract your attention from their bad suits and boring personalities, but is of no value if you just want to use a relational database management system. In fact, this is all you need to know to be a Caveman Database Programmer: A relational database is a big spreadsheet that several people can update simultaneously. A caveman I may be, but I tell you, if you can type SHOW PROCESSLIST, EXPLAIN PLAN, and CREATE INDEX with effect, write a self-join, and use the GROUP BY… HAVING syntax, many people will speak of you as they would of Gandalf. It's embarrassing, really.

gruseom 15y ago
A relational database is a big spreadsheet that several people can update simultaneously As someone who works on a "big spreadsheet that several people can update simultaneously", I can't resist making an off-topic comment. The analogy between spreadsheets and relational databases is seductive because both appear to use tables (actually, spreadsheets use a grid addressing system which only looks like a table). But really the two are from different planets: their data models as well as their computational models are incompatible. For example, compare how databases relate data (foreign keys) to how spreadsheets do it (cell references). What do these have in common? Basically nothing. The point may seem esoteric, but there have been lots of attempts to combine spreadsheets and databases and they all run aground on this mismatch. Crude integration a la import/export works ok, but the perennial dream of having a true spreadsheet on top of a relational database is out of the question unless you sacrifice efficiency, which you can't. I do wonder sometimes how far you could get implementing SQL on top of spreadsheet data. As an aside, it's interesting that the research literature on databases is vast and rich while the literature on spreadsheets (alas!) approximates nil.

gruseom 15y ago

A relational database is a big spreadsheet that several people can update simultaneously As someone who works on a "big spreadsheet that several people can update simultaneously", I can't resist making an off-topic comment. The analogy between spreadsheets and relational databases is seductive because both appear to use tables (actually, spreadsheets use a grid addressing system which only looks like a table). But really the two are from different planets: their data models as well as their computational models are incompatible. For example, compare how databases relate data (foreign keys) to how spreadsheets do it (cell references). What do these have in common? Basically nothing. The point may seem esoteric, but there have been lots of attempts to combine spreadsheets and databases and they all run aground on this mismatch. Crude integration a la import/export works ok, but the perennial dream of having a true spreadsheet on top of a relational database is out of the question unless you sacrifice efficiency, which you can't. I do wonder sometimes how far you could get implementing SQL on top of spreadsheet data. As an aside, it's interesting that the research literature on databases is vast and rich while the literature on spreadsheets (alas!) approximates nil.