views:

1111

answers:

8

We have just 'migrated' an SQL Server 2005 database from DEVEL into TEST. Somehow during the migration process the DB was changed from case insensitive to sensitive - so most SQL queries broke spectacularly.

What I would like to know, is - are there any clear benefits to having a case sensitive schema?

NOTE: By this I mean table names, column names, stored proc names etc. I am NOT referring to the actually data being stored in the tables.

At first inspection, I cannot find a valid reason that offers benefits over case insensitivity.

+2  A: 

Not all sections of Unicode have a bijective mapping between upper and lower-case characters — or even two sets of cases.

In those regions, "case-insensitivity" is a little meaningless, and probably misleading.

That's about all I can think of for now; in the ASCII set, unless you want Foo and foo to be different, I don't see the point.

Rich
Curious to know how many people are going to know what bijective means? :-). Those without basic set theory/combinatorics will be out in the dark without Wikipedia?
Bill
+1  A: 

Case insensitivity is a godsend when you have developers that fail to follow any sort of conventions when writing SQL or come from development languages where case insensitivity is the norm such as VB.

Generally speaking I find it easier to deal with databases where there is no possibility that ID, id, and Id are distinct fields.

Other than a personal preference for torture, I would strongly recommend you stay with case insensitivity.

The only database I ever worked on that was set up for case sensitivity was Great Plains. I found having to remember every single casing of their schema namings was painful. I have not had the privilege of working with more recent versions.

Unless it has changed and if my memory serves, the nature of case sensitivity you are speaking of is determined at installation time and is applied to all databases. It was the case with the SQL Server installion that ran the Great Plains database I mentioned that all databases on that installation were case sensitive.

Bill
+5  A: 

I really can't think of any good reason SQL identifiers should be case sensitive. I can think of one bad one, its the one MySQL gives for why their table names are case sensitive. Each table is a file on disk, your filesystem is case-sensitive and the MySQL devs forgot to table_file = lc(table_name). This is heaps of fun when you move a MySQL schema to a case-insensitive filesystem.

I can think of one big reason why they shouldn't be case sensitive.

Some schema author is going to be clever and decide that this_table obviously means something different from This_Table and make those two tables (or columns). You might as well write "insert bugs here" at that point in the schema.

Also, case-insensitivity lets you be more expressive in your SQL to emphasize tables and columns vs commands without being held to what the schema author decided to do.

SELECT this, that FROM Table;
Schwern
+3  A: 

Most languages out there are case-sensitive, as are most comparison algorithms, most file systems, etc. Case insensitivity is for lazy users. Although it does tend to make things easier to type, and does lead to many variants of the same names differing only by case.

Personally, between (MyTable, mytable, myTable, MYTABLE, MYTable, myTABLE, MyTaBlE), I would please like to see one universal version.

Justice
+8  A: 

I just found out why WE make it case sensitive. It is to ensure that when we deploy it on the client site, our DB works regardless whether the client's SQL Server is set up case sensitive or not.

That is one answer I wasn't expecting.

Jack
That's the only reason we'd do it, certainly.
nickd
The other answer: make half of your test systems case sensitive, and the other half insensitive. This will catch both classes of bugs.
Darron
We have different server collations on DEV and TEST. That ensures that we always specify the COLLATE on any temporary tables we create (e.g. in an SProc) and any date formatting that accidentally relies on server setup
Kristen
+1  A: 

I do support for Sybase Advantage Database Server and it uses a flat file format allowing DBF's as well as our own proprietary ADT format. The case where I see case sensitivity being an issue is when using our Linux version of the server. Linux is a case sensitive OS so we have an option in our db to lowercase all calls. This requires that the table files be lower case.

Joshery
+2  A: 

I like case-sensitivity, mostly because that's what I'm used to from programming in Perl (and most any other language too). I like using StudlyCaps for table names and all lower case with underscores for columns.

Of course, many databases allow you to quote names to enforce casing, like Postgres does. That seems like a reasonable approach as well.

Dave Rolsky
+1  A: 

I'm pretty sure the SQL Spec requires case folding (which is effectively the same as insensitivity) for identifiers. PostgreSQL folds to lower, ORACLE folds to upper.