I found that tweaking the ‘optimizer_search_depth‘ parameter (in my.cnf) for MySQL significantly sped up the query, as it told MySQL to only go so far in finding the best way to execute the query.

You can read more about it here: http://dev.mysql.com/doc/refman/5.0/en/controlling-optimizer.html

I’d recommend tweaking this variable to find the best level for your worst query.  For simple queries, they should be unaffected since MySQL doesn’t need to do much analysis on the best execution plan.  As an example, I’ve set the value to ’3′, and things are just fine.

To determine if you need this tweak, you can login to the MySQL console while a long-running process is executing and execute ‘SHOW PROCESSLIST\G‘.  If you see a query in ‘statistics’ state for more than a few seconds, try tweaking the value, and re-running the process.

The ORM then has a User, UserRole, and Role object to use in accessing these tables and adding / removing relationships with ease, since it only needs to worry about the single surrogate ‘id’ key on each table.  In the linking table (as a design concern), one should place a Unique Index on the user_id/role_id column combination.

The other option is using a composite candidate key.  I may have the specific terminology wrong, but the idea is that instead of the single surrogate key to identify a unique record in the linking table, you use a design like the diagram below, which combines the columns that are foreign keys to their respective tables to create the primary key.  The combination of the columns creates a unique identifying key.  The difficulty emerges with ORMs attempting to create objects out this design, and attempting to correctly generate the SQL required to make updates / deletes, etc, using each member of the composite key.

Personally speaking, I’m a fan of the surrogate key approach, but I’ve worked with both.  I won’t discuss the performance impacts of either design, since I don’t have nearly the research base to accurately describe it.  But, using simple integer based keys, the difference should be low.

I would like to be able to remove a single Foo, without having to first remove all the associated data from the other 3 tables.  Or, I know the ID of the Foo I want to remove, so instead of running multiple queries to find the associated rows, lets just knock it out with a single, multi-table delete!

DELETE
  db.zap as z,
  db.baz as bz,
  db.bar as z,
  db.foo as f
FROM
  db.zap as b,
  db.baz as bz,
  db.bar as z,
  db.foo as f
WHERE
  b.baz_id = bz.id AND
  b.zap_id = z.id AND
  bz.foo_id = f.id AND
  z.foo_id = f.id AND
  f.id = ?

This will then remove the rows associated with the single Foo record I’ve referenced, in one fell swoop.

ERD for storing ICD9 data

We see that diagnoses can have sub-diagnoses, etc. I used this simple structure, and added a qualifying column of ‘record_type’ to indicate if the code listed was an actual diagnosis, or a section header. Sections of diagnoses are part of the data, and can be used in searching the database. This diagram offers a simple and quick design to handle the data given.

Comments are welcome.

What I’ll be doing is going through some simple applications, and start modeling the tables and relationships, and intersperse some commentary where useful.  The discussion depends on interaction, and I’m of the opinion that a ‘good’ database designer can a) defend their design articulately and b) know when to concede a good point.

Database design is becoming organic.  Strict adherence to the normal forms isn’t required any longer.  Let me be clear though, denormalizing a table to make things easier for a developer is not a valid reason to denormalize.

The modeling tool I’ll be using for generating the images is MySQL Workbench.  Workbench is a very powerful tool, from the source of one of the most powerful (and used) databases today.  I cut my teeth on database design with DBDesigner4, whose creator went on to work for MySQL Workbench.

Stay tuned.