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 ...

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 ...

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 ...

The final numbered post in this version of my “pillar” series of posts ends in the most contestable part of the design/implementation process.  Encapsulation. The concept of encapsulation is not contested (or even contestable by sane programmers in any field of the art of system creation. Every time you use a Windows API call you are ...

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 ...

Okay, so on the first look this sounds like the most boring Japanese action movie ever. Requirements is tearing through the village, and Architecture is in the city.  Developers by the horde are trying to code both of these into oblivion…Maybe not.  Clearly I am talking about something a little more exciting…the battle between the forces ...