Related to "who can decrypt my data," I picked up a clue in this example: http://blogs.msdn.com/b/lcris/archive/2005/12/16/sql-server-2005-yet-another-column-encryption-demo-quot-clinic-quot.aspx

(This was linked on around page 4 of this thread)

When you create a certificate, you can specify the user that is allowed to use that cert.

So at the simplest level, you set up a specific account that is able to read and write to the DB, then create a cert that only they can use.

Even if you're SA, you can't use that cert, and thus you can't decrypt the data. (Of course, if you're SA, you can log in as the account, but that's a different story)

In my expected scenario, a web server will be writing most of the data to the database. I create an account for the web server, create a cert for that account, and now I can have encrypted data.

I can now give my developers enough access to do whatever it is they normally do, but not enough access to log in as the web server account-- they are now locked out of the encrypted data unless they get access to the web server credentials, which should be a standard password management issue anyway.

The article also shows how to chain certs so that you can have a master account with subordinate certs, so you could separately encrypt accounts payable and accounts receivable, but still allow one person to decrypt both.