Imagine a database of valued recipes. The company that keeps this database does not want you to know what ingredients go into their product. They also do not want you to know the cooking steps to make the given recipes. I can understand that in a case such as this hypothetical, those columns must be encrypted.

Now imagine a customer calling up and asking if the company makes a certain product, but some knucklehead encrypted the product column and the customer service person has to respond that they need 15 minutes to locate the DBA, decrypt that column, and then lookup whether or not they make the product.

On the one hand, you have an intelligent use of encryption of sensitive database columns. On the other hand, you have a DBA who has made a simple customer request a major project, cost the company time, money, and likely the customer is not going to hang around waiting.

This is the scenario I have faced many times in my career - DBAs who think everything under the Sun should be encrypted without thinking about the consequences and costs in time and effort to the company.

The answer? I would not agree that everything should be encrypted. I think the use of encryption, like many database features, has to be thought out beyond the mind of just the DBA. Indeed, the DBA is the last person to make this decision because usually, they are the people who do the least consuming of the database information. Leave this matter to Customer Service, Management, and the Customers - serve them!!! Not the DBAs often myopic idea of what amounts to sensitive data.