Name: Applied Mathematics for Database Professionals
ISBN: 9781430211846

What Hacker News says

dmfayMay 2022

Lex de Haan and Toon Koppelaars, Applied Mathematics for Database Professionals -- a fairly gentle introduction to database theory starting with logic & discrete math

Ralph Kimball and Margy Ross, The Data Warehouse Toolkit -- even if you're in an OLTP context, it's useful to know about warehousing techniques

Dmitri Fontaine, The Art of PostgreSQL -- cookbook approach to modern SQL with plenty of explanations

Not a book but Heinz Klein and Kalle Lyytinen's paper "Towards a New Understanding of Data Modeling" in the Software Development and Reality Construction remains a must-read 30 years later. The organizers of that conference have published a free PDF copy of SDRC if you look around a bit.

thread

ianamartinMay 2017

SQL was my entry point into software development, and I have a somewhat emotional attachment to it. And I'm quite glad that it worked that way.

SQL, relational theory, and set theory are a great place to start understanding how to work with data. And a great way to start understanding software.

All software deals with data. If you don't have a good understanding of data, you are never going to have a good understanding of software.

One of the best books I've ever read was Applied Mathematics for Database Professionals by Lex de Haan, and Toon Koppelaars. I think that's the database equivalent of SICP. You need to read it and understand it if you want to seriously deal with data. And you want to if you want to write software.

I'm obviously biased because of the way I got into things, but I look at things as a top-down vs a bottom-up point of view. I was a violinist and music theorist before I got into technology, and the bottom-up approach has always resonated with me.

In classical music, pretty much everything bubbles up from a baseline foundation and a structure; the stuff at the top that you actually see is a result of that structure. You don't start with some notes that you want to play on an instrument and then go and try to find a structure that supports those notes. You go bottom-up. You lay the foundation and build on that.

It was easy for me to map that idea of musical theory onto a database early in my career. And I moved up in the stack as I needed to. I started by building things entirely in SQL. You want complex statistical analysis? Sure, I'll do that . . . in SQL. Because I didn't know any better.

Then I found out that there are actually other languages that can do certain types of things much better. R, Python, C#, etc.

11 years later, I'm now very capable in a number of languages, and I don't suck. Along the way, I've had to put a lot of effort into learning the things I would have got from a comp sci degree program, and I'm probably not the best at certain types of software challenges.

I use noSQL stuff for caches and data warehouses, I use some of that for offloading traffic and keeping the reads separate from the writes. But there isn't a project that I touch that doesn't involve SQL in some way.

SQL is incredibly useful every day. Learning it, knowing it, understanding it, is a bare minimum for people I hire.

If you have a comp sci degree, and you don't know SQL, I'm going to probably write you off. If you have a liberal arts degree of some kind, and you do know SQL, I'm probably going to hire. You can learn everything else on the job.

None of that is an excuse for the totally shitty article linked here.

We use SQL today because it's good and it works. Not many languages can say that these days.

thread

zvmazMar 2024

I tried to study C. J. Date's books to understand relational theory... suffice it to say that I got nothing from his books, except a deep irritation partly due to his absolute pedantry...

I finally learned SQL with a gentle introduction by Alan Beaulieu. I stumbled upon another book that's about the theory: Applied Mathematics for Database Professionals, by Lex deHaan, and Toon Koppelaars. Maybe these authors will benevolently teach me relational theory.

But please avoid C. J. Date's books. And don't be him when writing a book or trying to explain something to another human being.

thread