Case sensitivity in comparisons is an aspect of computing that I'm surprised is still so widespread. I can't say it more clearly than this:
It's a pox on computing and needs to be eradicated.
I've recently been working at a site where a new case-sensitive SQL Server system is being implemented. I cannot begin to describe what a poor idea I think this is.
In the end, all that a case sensitive system allows you to do is:
- Have multiple identifiers
- Existing in the same scope
- And the names of the identifiers differ only by case
You'd have a hard time convincing me that that would ever be a good idea.
At least not for a system used by typical humans. No sensible person is ever going to be comfortable with "John Smith" being a different name to "john smith". And similarly, do you really want a single database table with a CustomerID column, a CustomerId column, and a customerID column?
Well I certainly don't.
In the new system that I mentioned, there are columns ending in ID, Id, etc. They haven't even been consistent in the naming of their case-sensitive objects.
And yes, I hear the "but what about private variables vs properties in languages like C#?" complaint:
- Age is the object's property
- age is where the object stores the value assigned to the property
Surely we can come up with a better naming convention than that. I've lost count of how many times I've seen people using the property when they meant the private variable or vice versa. It's just not sensible.
Now before I hear complaints that case matters, be clear that I'm not talking about case preservation; that's an entirely different thing. Yes, if I defined a column as CustomerName, I don't care if I query it by customername, Customername, etc. I want it coming back as CustomerName ie: however I defined it. Case preservation is a virtue; it's case sensitivity that I see as an almost always painful and unnecessary thing.
Worse, if you've ever tested an application against a case-sensitive server, you'll understand the challenges involved. It's hard to get case-sensitive code correct.
I gather that SQL Server Management Studio has a current bug that arises when you remove and re-add a database from an availability group on a case-sensitive server. Why? It appears that they aliased a table with A in one place, and used the alias as a in another place. It's really nonsense to have a situation where that matters but it highlights the other big issue. It makes for fragile applications.
Do you really want to be the one who's testing all your applications and 3rd party utilities to find out if they've tested case-sensitivity properly? Do the tools that you use have a better testing regime than SSMS? I'll bet that most don't. And what that means is that you get to spend your life wading through obscure tooling issues.
No thanks. Life is too short.