At the beginning of a new contract, I often find myself designing a database with people who don’t know much about database design. These people are my clients and their lack of database knowledge doesn’t matter much. We talk about their business logic and the specifics of how their data is related to itself.

I try to ask the questions that will make designing their database a no-brainer, but it’s never that easy. Instead, there are choices I have to make based on an educated forecast (or guess) of how I think their data will evolve over time. For best results, I get clients involved in the design of all nontrivial parts of their database.

But how do you talk “entity relationships” with clients who don’t know a lot about databases? I use pretty pictures. Not UML; there’s no need to trade one confusion with another. I make diagrams that zero in on one complex part of their database at a time. Simple pictures that I can use to talk with clients about their data relationships.

It’s critical to keep the amount of information in each diagram to a minimum. I put the same care into excluding any unneeded information from these diagrams as I do for sides in my keynote presentations. It’s all about clarity.

Here’s one of my diagrams (update: I fixed up this diagram as per Kubicek’s comment):

There’s not a whole lot of technical information here, but the basic relationship between tables is very clear. For more clarity I’ll add text that briefly explains a use case. I don’t let myself get hung up on rules about database diagramming.

I’ll present a diagram to a client and we use it to talk about how their application will work. I get them to think about how their data fits into the model I’m explaining and ideally, they tell me where I’ve gone wrong. I’ll revise the diagram until it fits. Then I design the corresponding tables and Active Record models and associations.

I find these diagrams extremely helpful in documenting complex associations. Later, I can look at a diagram and quickly remind myself how an area of a client’s application works before I jump in for some updates or bug fixes.

My Tools: I use OmniGraffle for most of these diagrams. If I need bigger guns, I’ll use Adobe Illustrator.

Some friends of mine at work just gave the table of contents for my book a substantial face lift. It's pretty cool how they dynamically generate the TOC and content preview from our MarkLogic content repository (an XML database). See what you think:

http://www.oreilly.com/catalog/9780596527310/toc.html

For long time now (~8 years) I've defined a debugging method called "yell", in many of my apps, for spitting out messages in times of heavy debugging. So far, there have been no name space conflicts, thanks to the off-the-wall name. Anyway, here what I add to any of my Rails projects where complex logic might require this type of brute-force debugging:

def yell(msg) 
  # stupid simple logging:
  f = File.open(File.expand_path(File.dirname(__FILE__) + "/../log/yell.log"),"a") 
  f.puts msg 
  f.close
end

What do you do?