I recently encountered a situation where I had a query that was built with quite a few joins (~8), and I found that the query was taking a bit longer than I expected, especially for the number of rows to look at / return.  With each join, you add in more complexity for MySQL to […]


In my previous post, I used a key style that is open to debate and has been for many years amongst DB folks. The idea of every table having a surrogate key, regardless of the purpose of the table. This says, that for any record in the table I have a single column that acts […]

MySQL provides cascading updates / deletes with the relationships, but I tend not to use them, specifically because I want to control just how far these updates and deletes cascade!  But, given a situation where I have a design similar to this: I would like to be able to remove a single Foo, without having […]

In today’s Adventures in Database Design, we’ll take a look at a relevant topic, ICD9 data. ICD9 data is the diagnosis and procedure codes used by insurance companies to categorize, well, diagnoses and procedures to be determined / performed by medical professionals. The design is simple, but very versatile, given the type of data we’re storing.

I’ve long neglected this blog, and the power behind it to discuss my feelings toward database design.  Proper database design is the backbone to a solid application.  Failing to correctly normalize tables and enforce business logic with foreign key relationships can cause undue headaches. What I’ll be doing is going through some simple applications, and […]