对区分大小写的数据库有好处吗？

Question

我们刚刚将一个SQL Server 2005数据库从DEVEL迁移到TEST中。不知何故，在迁移过程中，数据库从不区分大小写变为敏感 - 所以大多数SQL查询都突然壮观。

我想知道的是 - 对于区分大小写的模式有没有明显的好处？

注意：由此我的意思是表名称，列名称，存储过程名称等我不是指实际上存储在表中的数据。

在第一次检查时，我找不到一个有效的原因，提供优于大小写不敏感。

Answer 1

我刚刚发现我们为什么要区分大小写。确保当我们将它部署到客户端站点时，无论客户端的SQL Server是否设置为区分大小写，我们的数据库都可以工作。

这是我没有预料到的一个答案。

Answer 2

不是Unicode的所有部分都在大写和小写字符之间有一个双射映射 - 甚至两套情况。

在这些地区，“不区分大小写”有点没有意义，并且可能会产生误导。

这就是我现在能想到的所有东西;在ASCII集中，除非你想让Foo和foo不同，否则我没有看到这一点。

Answer 3

如果开发人员在编写SQL时没有遵循任何惯例，或者来自不区分大小写的开发语言（如VB），则不区分大小写是天赐之物。

一般来说，我觉得处理数据库更容易，因为ID，ID和ID不可能是不同的字段。

除了个人对酷刑的偏好之外，我强烈建议您保持不区分大小写。

我曾经为此设置过的唯一一个数据库是为Great Plains设置的。我发现不得不记住他们的模式命名的每一个框架是痛苦的。我没有使用更新版本的特权。

除非它已经改变，并且如果我的内存正常工作，则说明的大小写敏感性的性质在安装时确定并应用于所有数据库。运行Great Plains数据库的SQL Server安装就是这种情况，我提到该安装上的所有数据库都区分大小写。

Answer 4

我真的想不出任何好的理由SQL标识符应区分大小写。我可以想到一个不好的之一，它的一个MySQL为什么他们的表名是区分大小写的。每个表格都是磁盘上的文件，您的文件系统区分大小写，MySQL开发人员忘记了table_file = lc(table_name)。当您将MySQL架构移动到不区分大小写的文件系统时，这非常有趣。

我可以想到他们不应区分大小写的一个重要原因。

某些架构作者会很聪明，并且认为this_table显然意味着与This_Table不同，并且创建这两个表（或列）。您最好在模式中编写“插入错误”。

此外，不区分大小写可以让您在SQL中更具表现力，以强调表和列与命令，而不必拘泥于架构作者决定执行的操作。

SELECT this, that FROM Table; 

Answer 5

大多数语言在那里是大小写敏感的，因为最比较算法，大多数文件系统，等等忽略大小写懒惰的用户。虽然它倾向于使事情变得更容易，并且会导致只有大小写不同的相同名称的许多变体。

个人，（MyTable的，MYTABLE，myTable的，MYTABLE，MYTABLE，MYTABLE，MYTABLE）之间，我会请看到一个通用版本。

Answer 6

我支持Sybase Advantage数据库服务器，它使用的平面文件格式允许DBF以及我们自己的专有ADT格式。我认为区分大小写是一个问题的情况是使用我们的Linux版本的服务器。 Linux是一个区分大小写的操作系统，所以我们在db中有一个选项来小写所有的调用。这要求表格文件是小写的。

Answer 7

我喜欢区分大小写，主要是因为这就是我习惯从Perl编程（以及大多数其他语言）。我喜欢使用StudlyCaps表名和所有使用下划线的小写字母。

当然，许多数据库允许引用名称来强制套用，就像Postgres那样。这似乎也是一个合理的方法。

Answer 8

我很确定SQL Spec需要标识符的大小写折叠（实际上与不敏感性相同）。 PostgreSQL折叠降低，ORACLE折叠到较高。