我们刚刚将一个 SQL Server 2005 数据库从 DEVEL 迁移到了 TEST。不知何故，在迁移过程中，数据库从不区分大小写变为区分大小写 - 所以大多数 SQL 查询都被严重破坏了。
我想知道的是 - 拥有区分大小写的架构有什么明显的好处吗？
注意：我的意思是表名、列名、存储过程名称等。我不是指存储在表中的实际数据。
在第一次检查时，我找不到比不区分大小写更有利的正当理由。
【问题讨论】：
标签： sql-server database
我刚刚发现我们为什么要区分大小写。这是为了确保当我们在客户端站点上部署它时，无论客户端的 SQL Server 是否设置了区分大小写，我们的 DB 都能正常工作。
这是一个出乎我意料的答案。
【讨论】：
我真的想不出任何好的理由 SQL 标识符应该区分大小写。我能想到一个 bad 之一，它是 MySQL 给出的为什么它们的表名区分大小写的原因。每个表都是磁盘上的一个文件，您的文件系统区分大小写，MySQL 开发人员忘记了table_file = lc(table_name)。当您将 MySQL 模式移动到不区分大小写的文件系统时，这非常有趣。
我能想到为什么它们不应该区分大小写的一个重要原因。
一些架构作者会很聪明，并决定 this_table 显然意味着与 This_Table 不同的东西，并制作这两个表（或列）。您不妨在架构中的那一点上写“在此处插入错误”。
此外，不区分大小写可让您在 SQL 中更具表现力，以强调表和列与命令，而不必拘泥于架构作者决定做的事情。
SELECT this, that FROM Table;
【讨论】：
并非 Unicode 的所有部分都具有大小写字符之间的双射映射——甚至是两组大小写。
在这些地区，“不区分大小写”有点没有意义，而且可能会产生误导。
目前我能想到的就这些了；在 ASCII 集中，除非您希望 Foo 和 foo 不同，否则我看不到重点。
【讨论】：
大多数语言都区分大小写，大多数比较算法、大多数文件系统等也是如此。不区分大小写适用于懒惰的用户。尽管它确实倾向于使输入更容易，并且确实会导致许多相同名称的变体只是大小写不同。
就个人而言，在（MyTable、mytable、myTable、MYTABLE、MYTable、myTABLE、MyTaBlE）之间，我请希望看到一个通用版本。
【讨论】：
如果您的开发人员在编写 SQL 时未能遵循任何类型的约定，或者来自不区分大小写是常态的开发语言（例如 VB），那么不区分大小写是天赐之物。
一般来说，我发现处理 ID、id 和 Id 不可能是不同字段的数据库更容易。
除了个人偏好酷刑之外，我强烈建议您不要区分大小写。
我曾经研究过的唯一一个区分大小写的数据库是 Great Plains。我发现必须记住他们模式命名的每一个外壳是很痛苦的。我没有使用更新版本的特权。
除非它已更改并且如果我没记错的话，您所说的区分大小写的性质是在安装时确定的，并且适用于所有数据库。运行 Great Plains 数据库的 SQL Server 安装就是这种情况，我提到该安装上的所有数据库都区分大小写。
【讨论】：
我喜欢区分大小写，主要是因为这是我使用 Perl（以及大多数其他语言）编程时所习惯的。我喜欢使用 StudlyCaps 作为表名，所有小写字母和下划线作为列名。
当然，许多数据库允许您引用名称以强制大小写，就像 Postgres 一样。这似乎也是一种合理的方法。
【讨论】：
我确实支持 Sybase Advantage 数据库服务器，它使用平面文件格式，允许 DBF 以及我们自己的专有 ADT 格式。我认为区分大小写是一个问题的情况是在使用我们的 Linux 版本的服务器时。 Linux 是一个区分大小写的操作系统，因此我们可以在我们的数据库中选择小写所有调用。这要求表格文件为小写。
【讨论】：
我很确定 SQL 规范要求标识符的大小写折叠（实际上与不敏感相同）。 PostgreSQL 折叠到下，ORACLE 折叠到上。
【讨论】：