Why musicians make good programmers

I was chatting to someone the other day and we got talking about the other things we did besides programming.  It turns out that both of us were musicians.  I got to thinking and realized that I knew at least six technical people who were also musicians -- and pretty good ones, at that.

It's an old maxim that musicians are likely to make good programmers, but most of the time the reasons why it might be true are left unsaid.  I've received the impression that the association is something like music --> rhythm --> counting --> math --> programming.

Personally, I think the reasons are quite other.  As someone who's spent a long time doing both, I think that what programming and instrumental music performance study have in common is a certain set of mental skills.  In both cases, you have to take something that's quite abstract (and perhaps only vaguely conceived), flesh out its shape in your mind, take it apart, put it back together, and then translate it into something concrete:  property definitions, muscle movements, rises and falls in volume.  There's a degree of analytical skill, pattern-matching, and pattern-mapping that's required in both. 

Relational Integrity and Candidate Keys

On my current project, we're not using natural, semantic keys:  we're using Guids for primary keys and enforcing unique constraints on the combination of columns that make up the candidate keys.  And this is fine for most purposes, but there's an aspect of relational integrity that gets left out.

Consider a system that schedules events within multiple buildings for multiple organizations.  Some tables might include the following:

OrganizationalSchedule

  ScheduleId   PRIMARY KEY

  OrganizationId

  FiscalYearId

Speakers

  SpeakerId PRIMARY KEY

  OrganizationId

  Name

Event

  EventId PRIMARY KEY

  OrganizationalScheduleId

  SpeakerId

  Date

Assume the obvious foreign key relationships and implied Organization parent table.

Now, you will want your SpeakerId in the Event table to be of a speaker whose Speaker record has the same Organization Id as the Organizational Schedule record does.  But how are you going to relate the records in order to assure this? 

In SQL Server 2008, I don't think you can, not directly, unless you're using natural keys as the actual primary keys.  So I'm looking at check constraints that use UDFs and the possibility of triggers.