Or you encrypt the value you want to look for before using it in your WHERE clause. Unless the key is individually salted for each person, you can do a much quicker binary comparison with encrypted value against encrypted value. If it IS individually salted, you could store a hash to compare with rather than the full value, decreasing the amount of work that needs to be done. As far as I'm aware, performing a hash operation + compare would be quicker than full decryption + compare. If you don't salt the hash, it's even faster, though an attacker would be able to use a rainbow table then.

Besides, CSRs and billing would only need the encrypted data occasionally anyway. It wouldn't be a huge overhead to decrypt if you only run billing once a month - let it go overnight. You could even split it across the month, running portions at a time depending on the billing date for each customer.

I'd venture a guess that you're not using:

• TFS - lag on every operation that gets worse the more files you have checked out, and the larger your source tree is. I've had it take several minutes to rename a single file. As soon as you do a check-in, suddenly it's back to instantaneous.
• Database projects - lag that gets worse the more complex the project is. Save a file, wait 20 seconds. Save a lot of files, you might as well go to lunch. Don't even think about referencing other projects. And if Visual Studio crashes, you lose an hour whilst it regenerates the database model.
• Silverlight projects - Start getting to a decent size, and you'll endure multi-second lags every time you switch tabs. Make that double if the tab is a XAML designer. And the build times are glacial.

I should note these experiences were all on a quad-core, 8gb of RAM 64-bit version of Vista, but we had developers on XP and Windows 7 finding exactly the same.

Thank goodness I don't have to deal with Visual Studio any more. It's fine for small projects, but as soon as you start having large, enterprise-scale applications, the constant freezes and lag become unbearable.

I'd argue Openmoko failed because they were too busy making shiny user interfaces to get the thing working.

It had nothing to do with the level of lock-down and everything to do with the thing not even covering the essentials of being a phone, let alone smartphone. Just the little things, like... say, making and receiving phone calls reliably, or being able to have it suspend and actually work when it woke up.

The hardware wasn't so bad, but they seemed to think that being open source would magically provide them with functioning software.

Most likely the missing 0.3% is makefiles and miscellaneous scripts.