In this last kind of “creative” chapter, I will look at some of the ways you implement common problems in your relational database, and some of the ways you probably shouldn’t. The “should” sections will deal with: Uniqueness – Beyond the simple uniqueness we have covered in the first chapters of the book, looking at some very realistic ...

As the book progresses, I find myself veering from the original stated outline quite a bit, because as I teach about this more (and I am teaching a daylong db design class in August at http://www.sqlsolstice.com/… shameless plug, but it is on topic :) I start to find that a given order works better. Originally I had slated myself to talk more ...

A while back, I was working on a short article about Normalization for a book that never got published (admittedly I wasn’t getting paid for the article, and it wasn’t for charity, so I wasn’t that broken up over it.)  The task at hand was to, in 2 pages or less, describe the process of normalization and help you to know when you have ...

I am trying to blog all of the chapters of the book, but due to deadlines and a lot of shuffling about, I never got around it for these three chapters, two of which I have added since I wrote the original table of contents. All of these contain mostly material from previous editions of the book, updated a good amount, but nothing tremendously ...

So, it is right there in the title of the book “Relational Database Design” etc (the title is kinda long :)  But as I consider what to cover and, conversely, what not to cover, dimensional design inevitably pops up. So I am considering including it in the book. One thing I try to do is to cover topics to a level where you can start using it ...

One of the main things that I haven’t always loved about the previous books is that it wasn’t a perfect reference book. I focused on having a flow throughout the book that, not unlike a school class, started at the beginning and finished at the end. Interspersed were semi-cohesive examples that followed along in an entire chapter (once even for ...

The more I teach sessions about database design, the more I realize that two things are true. First, most people don’t dig the normalization stuff as much as I do (some do), and second, people really need the normalization stuff more than they think. The really hard part is how to flavor the medicine just enough such that it will be read by more ...

A bit of terminology that gets beaten to death is that of the “physical” database.  I would think most every DBA uses this term (I do), but…to mean what?  I think there are two common utilizations: The layer of tables, constraints, indexes, etc used to store data The actual on-disk structures. Frankly, until 3 years ago, I ...

I have gotten a few more reviews in, and interestingly I appreciate the negative ones almost as much as the positive ones. I prefer the negative ones that have decent star ratings better… but what are you going to do. The most recent review was critical of the book for not having mentioned testing. I actually think that this was really good ...