Designing Data-Intensive Applications https://dataintensive.net/
Streaming Systems http://shop.oreilly.com/product/0636920073994.do
and this one.
There are tons of open-source databases on github that you can hack on so I don't think there's a major issue with getting practical experience if you want it.
What’s the sell here?
If I was mentoring someone learning this stuff, I'd advise reading Designing Data Intensive Applications first, which is certainly the best for giving the big picture, and follow up with this one for more detail on certain topics.
Given the previous dearth of books on this important subject, I think it's wonderful that we have two.
I haven't seen the book you mentioned, so I can't comment on that.
Here's the landing page for the book's implementation: http://www.cs.bc.edu/~sciore/simpledb/intro.html
Unfortunately, I don't think the book is in print anymore.
Advice to all web designers: Please do not use "font-weight: 300" for body text, ever. Simply changing that to 400 in the developer tools made it much more readable. The font was still bugging me, so I tried killing the "font-family: futura pt" too.
Wow! What a world of difference. Now it is super easy to read, instead of looking like it's trying to show off some design style.
Know your audience: you are addressing potential database developers with this book, not graphic designers.
What makes this book so much better?
Database internals books are not worth reading if you want to work on implementing real world database engines. You are better off checking out internals and documentation of various implementations and also research papers in that field. And you would be doing your own research anyway.
But if you are just starting out in programming, it's probably as good book as any to learn something new and practical about algorithms and data structures.
Some of the folks I talked to who have already worked with databases a lot mentioned they've benefited from the book as well, since there were some concepts they were less familiar with or never had to learn (for example, transactional processing for the folks who have mostly worked with on eventually consistent databases; or B-Tree details for the folks who have mostly worked on LSM-Based storage engine)
Disclaimer: I'm author of this book.
Because if it is, I would be miffed and feel short changed to be told to watch youtube lectures on my own time. I value face to face time and interactivity with my professor or lecturer. If this is a heavily discounted course due to the crippled way it is taught then I have no issue.
From the syllabus:
CS144 is taught using a combination of lectures and videos. In previous years, it was entirely “flipped”; i.e. all the lecture material was taught by videos. This year things are different and we are going to mix things up: Some weeks, including the first week, will be based on recorded videos that you are required to watch in your own time. We will call these Video Weeks. Other weeks, including the second week, are based entirely on in-class lectures, and you don’t need to watch any videos. We will call these Lecture-only Weeks. So why mix things up? We are teaching this way because we have found that some of the material (e.g. the basic principles you learn in week 1) are most efficiently learned by watching videos - the concepts are fairly simple and the material is descriptive; a video is a more efficient use of your time. Other material, such as when you learn about congestion control in week 4, is best learned in person, interactively in a lecture.
Those that don't need the piece of paper can learn for free. Who can complain about that!
I also might not understand the purpose of the video lectures. If they supplant face to face time but get rid of the tedium, then I would say it should also accompany course/lecture notes, reading texts, and/or supplemental documents.
I just think forcing people to watch youtube videos is a much lower quality experience for a student. If it's a required course I'd want a refund for being forced into a lazy teaching format.
